Update: last few weeks

I don't really normally do update blog posts, but I feel that it is a good idea this time.
So during last week I had the flu. A pretty nasty one at that. While that stopped me pretty much programming during it, it did allow me to gain a new perspective on things.

I took another look at Cmsed's status. And I found the user authentication lacking. That the generation of javascript also quite lacking.
To fix this I completed the query generation of data models. I haven't precisely tested it live, but I believe if it doesn't work correctly it can be made to.
Further a few fixes for routes javascript generation.


To help with the javascript, as its quite 'large' I ported a minifier to D from. It was quite a nice one and worked first time surprisingly. However because of it being PHP it meant I had to live deduct its types and fix them as required. Also it was quite a nasty surprise to discover that it was designed for not just ASCII this meant changing everything to wchar/wstring. In turn making conversion a bit of a hassle.
Its available by default for static javascript files during a release build. There is nothing to configure or disable with regards to it.

Yesterday I worked upon a very new (unplanned) feature that being policies for users and groups. It means that you have the ability to apply rules to groups and specific users at runtime. A policy is essentially just a name. However a policy can be applied to a user/group but disabled if for some reason it was wanted.

Today I was working upon two projects. My actors for D (Dakka) and Cmsed again. Unfortunately some weird bugs came up with Dvorm so that had to be fixed.
For Cmsed adding of a base for database storage of all nodes being operated was added. This will be used by Dakka to know what other nodes are out there. The specific capabilities will be pushed into configuration later.
For Dakka I begun by fixing up a bug or two that was left over from previous testing involving pack-d. Next was to begin work on support for remote calls to other nodes. Initially and as of this writing there is no security being pushed over it. Considering that this system should be secured within a private server network its not of a top priority. However it shouldn't be too hard thanks to Vibe.
At this point Dakka needs to make remotes work is two parts. Queues to handle getting requests/responses via sockets. Lastly a load distributor. I have a very clever and simple trick. First when connect a time packet will be sent to compare times on each system. This is an offset. For every request after it, it'll be negated off the value. Every two iterations of the socket's loop a new time packet will be sent and hence checked. Once it gets too high it'll be considered read only in terms of new addresses till it gets down again.

Once Dakka has working node communication for remotes I will consider it feature complete. And hence will go up on github. Furthermore it'll be integrated into Cmsed. And with that some really neat features for larger web services will become available.

What I'll probably do is add support for managing docker containers (think VMs). Which would have some rather nice side effects like easily building a web service to do compilation.

There is something bothering me however. Its about Dvorm. Not so much what it does now, but what it should probably do. The whole idea of not currently supporting relational databases really really scares me. And each design I have to solve this doesn't fit right. So I'm coming to the conclusion that there is no way I can personally take care of the differences between the databases. I'm also worried that a lot of code I write using queries really should be e.g. inner joins if it were sql. And the current query syntax doesn't support this. But I have the relationship UDA's so in theory it should be possible to do:
.query().id_eq("123456789").get_prop();

Instead of:
.query().id_eq("123456789").findAll()[0].prop.getType();

Type of deal. With quite a bit of user created code in that.
One other syntax I would like to support:
ChildType.query().timeSet_lt(oneHourAgo).findAll_parentTypeProp which would:

For every child that is older than one hour return its parents value based upon its value in property.

But this is just some ramblings at like half past four in the morning of some crazy ideas I have floating around.