Future is bright, I think?

I'm coming up to a major part of my life. Not anything like marriage however. My BCCE301 industry project.
Where by I will be working with industry to do a project in some form. Now my plan is to start to a company where by making a web service utilising D.
Ignoring the major issue of money in doing so, what other challengers will I have in doing this?

Unfortunately my libraries today are no where near ready to do this. Cmsed is a complete mess and with high reload times is not preferable. Duml can't output templated classes/methods. Dakka can't even call other processes actors. Dvorm is the only thing pretty much ready to go and its the simplest.

So how exactly am I going to do this? Well thats where my evil ideas will come into play.
First off, Dakka is the key to my end goal. Cmsed is the next key component. Hopefully Tipdl will also be there.
Tipdl is a templating language / library that will taken advantage of Cmsed's javascript generation techniques, which is a little similar to Erlang's Nitrogen's templates. It will enable hooking into and exporting routes as a path using arguments, ajax calls based upon routes. It would be used to generate D files which would then be compiled in as needed.

So why the central focus on an Actor framework for? Thats the clever part.

1. Want to recompile a route? Easy. Do the compilation, start the process, stop the previous one.
2. Node communication. A lot of the project I have in mind will be based upon a multi tier approach. In this case its important to be able to have front end web servers call a backend node to say, go do some processor intensive task. Which does need to be load balanced.

Unfortunately this means that Cmsed is completely ill structured. For example there is two different modes it can compile routes/templates in.

• As part of the main build
• Using Dakka to execute them

At this point Cmsed's router takes advantage of not having to reimplement a bunch of stuff with Vibe.d. But with this new approach, a lot will have to be. In fact a Dakka node will need to emulate a lot of the functionality so that it can then be pushed to the client in the host application safely. I really don't want anybody to use some property or function that essentially equates to write to the socket.

The router in its current state could be used with Dakka, however modifications should be made so it gives preferential treatment to compiled in routes and then sequentially calls the appropriate Dakka nodes.

Javascript generation would have to be pushed off into the Dakka nodes as well. And hence for every Dakka node it will have to support both the routes themselves but also the static files.

Further the new structure of Cmsed projects will be vastly different. No more hit and miss dependency mechanism. Oh no. Say hello to:

├── deps

│   └── package.json

├── dynamic

│   ├── bin

│   ├── config

│   ├── models

│   ├── public

│   ├── routes

│   └── templates

└── static

    ├── models

    ├── public

    ├── routes

    └── templates

Okay first off, the dynamic and static directories are almost identical with the exception of dynamic including bin and config. The bin directory will be used for the nodes that is compiled at runtime; config will be for the nodes config.

Models, routes, templates and public should be fairly obvious as to their purpose.
The differentiation between static and dynamic will mean that only the routes ext. you want compiled in will be during development. Of course forcing all to be compiled in will be possible for releases.
The deps directory will be used for dependencies that all dynamic nodes and the host application will be compiled against. Of course the host application will be a bit different.

This will of course, will generate the question. How do I create this? Right now there is no skeleton generator post dub's init command. For this, dub can actually indirectly help. Using dub run for a non installed package would work well. So:

dub run skeletons github:rikkimax/cmsed/skeletons/base.json

My github repository cmsed inside a directory called skeletons grab a file called base.json that describes how to create it. But this is just a simple idea. OS repository managers on the other hand probably will make it installable under a different name. But no matter.


So much cool stuff is coming, now just for the hard slog!