What I try to do now is to create the kernel features. The absolute minimum that my system must provide to an external developer for using just anything in the actual, dust-based environment. I have hit a serious question about control. When communicating with other components, I need to support the following tasks:
- direct call to another component, then continue the actual operation using the response (like evaluating an expression or alike);
- broadcast to a set of components (either through an iterated member field, or a result of a query), then either wait for the results, or continue operation, either synchronous or asynchronous way;
- set one or more relay components, either parallel or serial way (like in the interpreter, junction or sequence), either waiting for the return (and continue, like processing the closing block in a stream) or just let it go.
This can be done, my problem is with the "wait or not" question. If I wait, I need kernel functions to do this. If it is at the end, I need a special return constant to inform the kernel that it has to do so. I hate parallel stuff, and not straightforward solutions. If I support calls only, the kernel does not know if it has to do anything after the call, if it is at the end of the caller function. If I support return type only, the code becomes ugly and fragmented. None of them are acceptable.
Do I look in the wrong direction? A weird, but possible answer is: yes.
I keep thinking about providing a programming language interface, API for using dust, with generated codes, etc. At the same time, I think about an interpreter that allows fully functional dust programming above the language layer. What if I turn it upside down?
I can say that dust has no programming interface. I have to "implement" my services using the declarative tools, without using any generated code. The only codes appear at the edges: when a component brings a functionality from the external environment (runtime, like JRE, threading, stream, etc.; or external toolkit, like a database connector, GUI library, etc.) So, I only need
- structure constants that the real codes can use to access data stored in their own connector data objects;
- connector constructs that help the loader to connect the functions/objects to the aspect message processors;
- and perhaps some generic tool functions that I always implement in all language environments to speed up development (in Java, StringBuilder manipulations, arrays, ...).
However, there is no need to support programmatic connection between custom codes. This is fundamentally modifies the role and core features of the shared kernel codes. That is:
- no entity evocation,
- no message sending, call management, relay, etc - they go out to the core feature set available from the algorithm configurations...
This is most strange because I generally hate when configuration hacks replace source codes. On the other hand, I expose the structure to the framework and that looks great - I can do the same with the algorithms as well, that may be beneficial. My experience, and the currently growing number of interpreted script languages show that the common runtime performance allows this approach (the algorithm tree is exactly the same as a parsed script code). And there is still the option to generate source code or compiled binary from this tree... It is so unfamiliar because almost all codes that I have written so far or imagined in dust just disappeared.
The new approach also modifies the kernel implementation approach. So far I thought of the dust kernel as just another collection of components that talk with each other. Now it seems that the kernel components can be more interconnected as a Java implementation of this runtime, because there is no such thing as "dust code".
The implementation order:
- the shared parts (public include, shared Java toolkit project);
- kernel (with its modules perhaps in separate projects, but they can be interconnected on Java layer)
- external tools for the kernel (all for which normal dust communication is enough, like stream, log, etc)
- behavior (control execution, and expression evaluation)
