Self containing framework

And here I am again at the root question: how does a Dust application start up? With the addition of the new idea that "there is no Dust framework"... The latter means that there is no static entry point, no framework functions; all such thing are done by the kondutos of the Dust core terms. The only interesting thing is that the "main" function has to set up those items and connect them to each other: this core component network is able to serve the basic functions: message passing and data/reference access requests. Later, when I can add other unuos like serialization, binary loading, GUI, etc, then the framework can stand on its feet.

But first of all, I have to start up the self containing core service network. To do this, I have to create a kunteksto, and put the root components into it in the root initialization call. This code will be generated later from the system deployment information, but now of course I have to write this code myself.

The kunteksto, as this will go later, can be modified in a transaction. I can send ento initialization information (not actual instances, because the objects must be created by the kunteksto - on the other hand: how can the kunteksto create external, not yet added types? hmm...) The ento contains one or more aspektos with initial data and references to other entos. The references are resolved in a lazy creation fashion, so the referred ones get placeholders in the kunteksto, and later when their actual content arrives, are initialized. At the end, the transaction is committed - at this point this means the kunteksto runs a consistency check if all the references are resolved. The kunteksto ento is added to itself (because it is also referred from the entos inside).

At this point I will have a kunteksto from which I can access different functions, but naturally it would not be "Dust-like", so instead of this, I also have to add a test "Runnable" ento, and do those actions in its run message processor. Later on, drivers, external message handlers, etc. will be "Runnable" and started in this way.

Identifiers

This is where the nice idea seems to fail. The identifier (identigilo) is a string constant; the instance should represent its own name. The instance should be

• accessible for the user codes (in generated sources the coder will use them);
• should not be mixed with external objects (cannot be created by the user code, and the messages should contain only these constant values)

It is so nice that I keep forgetting what I already thought over... All components, including this initial framework core is inside a realigo: it has a connection interface to the framework - to itself. The identifiers are generated source codes: enums; the access functions use these enums. On the other hand, the framework resolves the names (the enum name strings) to actual identifier instances, which are lazy created. Now I have to type the eums, but later on that code will also be generated from the identigilos in the unuo. The enum strings are loaded into the global identifier table, and also attached to the enum order number table contained in the realigo. So the client code refers to the table index through the enum, and the reference is resolved by the framework by the enum name at the first call.

The only difference is that during the initialization, this local index table is pushed directly into the kunteksto from the source code.

What to add?

... to be continued...