This is a tough one because my Don Quixote like struggle with this probably impossible dream is one of the most intimate (but not private) parts of my life. However, I have shared the plans and the source codes, so the "static part" of the stuff is already public. I also hope that writing this log will help me stay on the path, will waste less time every time I start the day and get a bit of motivation like "I should do something nice today for the blog..."
Also, the wiki should contain static information and the questions and failures with all the experience from them have no real home there. So this is the place for my findings, those that finally enter the code and those that become failures.
I decided to do this in English simply because
- those who know programming enough to understand the content here will surely know English enough to read it
- this belongs to the Dust Framework documentation more than to the ordinary content of this blog (but I don't want to create multiple blogs) and that documentation is also in English
- and anyway, I do use English more in my programming-related writing (and perhaps even thinking) than Hungarian, despite the quality of my language knowledge.
Quick summary of the current situation.
I have thought a lot about how to go forward. I have written a lot into the wiki, but that is simple text, and at a certain point I needed a more hierarchical planning method. I then switched to Edraw, a quite fine mind mapping and drawing tool, created the basic layout of the components. Alas, the finer plans took too much efforts to draw, and was very similar to writing code, which I can do much faster than making a good looking diagram that I will surely have to transform to source code (and keep the two in sync).
So now I write C source as a method of planning. The first level is a kind of pseudo-code, as there is no real implementation behind the functions, but this approach pushes me forward to actual coding questions like component separation and function visibility. I hope this "planning" will eventually turn into a working kernel onto which I can build the core service layer (of course all in POC level).
I am quite confident about the Dust API, which is some enums and ten functions, although these are "collector" functions, like managing a field may mean copying its value out from or into the entity. I feel that in any declarative environment it can be easier to use the same function for a group of actions as long as their parameters are the same.
I have almost entered the first layer of the Dust kernel, which is Context: this is the place where the current kernel call is dressed up with its background information (unit, thread call stack, temporal local variables and transaction state). The next step is to move forward towards the implementation of the first API call, dustGetReferredEntity(). Along the "pseudo-coding" I have hit a synchronization problem and incorrect code structure: the entity map is actually not a passive collector, but I want to use it as an id-based cache with a factory in the background. I don't care if the required entity was there or not at the time of requesting it, I want to get that entity back, either from the cache, or created and probably stored at the time of my call. Considering other service components, some of them would actually use their id maps in the same way. So, this is a "special class of maps" and should be properly supported, the user code has no interest in its internal operations.
I should continue with creating the interface for this LazyMap, and use it in the context function. Then I can go forward to Unit Manager level, where a similar LazyMap will be responsible for providing the caller with the actual unit information block, and the definition of the referred type for creation.
