- access connected other instances: the connection itself is done through a local ID mapped to the target instance in the deployment
- access values through a variant interface
- send messages to the connected instances (targeted messages)
- send messages to the component's own broadcast channels.
Question: do I need the programming language at all, if its use is reduced to this level, and the above actions can also be used in declarative environments as "action nodes"? I could create the tree of action nodes directly, the same structure that the compiler actually creates when it parses the source code - and I could also parse source code to this structure, and play it in an interpreting environment with the above functions.
Answer: the lowest level, architecture dependent layer has to be programmed directly. I should identify the components of the execution layer (like memory, thread, "class loader" etc.) declare the same way as the lowest level data components (type, field, entity, aspect, channel, ...). The core functionality, process path has to be declared and played using the core items to find the terms and sentences of that layer. In this way I will have a configurable, segmented running environment instead of a monolithic "runtime". Then I will be ready to write that lowest level code for one architecture (be it Java, an OS or else).
When dealing with the abilities of the environment, I must forget actual programming languages and their features: I have to focus on what I want from the environment and why I want it. If I find the right approach, I can be sure that the actual language will help me in implementing it. So, what to support?
Exceptions
Components should not "peek into" the deployment path. When I require a service, I don't know how it will be implemented in the actual environment, like I want to access an entity, and I don't want to know that my environment resolves a storage address and requires the instance at this moment via HTTP requests from multiple servers that execute DB or LDAP queries for me. All points may fail due to different reasons; some should be handled and post processed before reaching me, some should never reach me, etc.
Therefore I should support throwing exceptions in the way of ordinal messages. The environment should immediately stop execution and roll back the operations until a catch is registered. The catch declaration should not break unit boundaries: a unit can catch its own exceptions and react to them in the finest detail (actual exception objects). The exception can be classified to different categories, and catch declaration can refer to these categories. This is a hierarchical structure, and for data I use the entity -> aspect* concept for them. Should I use the same here?
Looks fine. The server encounters an LDAP error, creates and throws an LDAP exception with all the details. However, this exception is private (security reasons) and should never leave the server machine (it is removed from the entity when it gets into an outgoing channel). On the other hand, it can be caught, and another (public) aspect can be added: temporal server error exception, perhaps with a short explanation and the estimated availability information.
Entity meta-type
Okay, so the Entity has a kind of "meta-type aspect", which can be Exception, Persistent Data, Temporal Data, Worker Component?
What is a worker component? That is like a configured parser, a stream channel, a GUI panel. But is it different from any other data? Its life cycle is limited to a session: though some of them "live" as long as the actual running hardware is switched on (the environment components); some are limited to a specific user action (GUI elements); some are even more temporal (event process nodes in a parser). But Temporal Data, the shortest living items (messages) need a life cycle management: should not be disposed when used, should be disposed when all user components finished with them.
One entity may have different life cycle aspects. A GUI element has Persistent Data components: the GUI structure and message path declaration is persistent, it is part of the service declaration; in normal case it is final. However, multiple instances (entities) can refer to the same declaration: multiple windows of the same service type. They are different because the Temporal Data section of the entities are different: actual size, location, language, ... Some of the Temporal Data section MAY be used to update the Persistent section (default location, size, language) - or the declaration can contain Temporal content as well that act as default. The latter is the better: less administration.
Is worker component limited to its actual location (machine)? NO. The Worker Component data can travel through a channel and appear on another machine (for GUI, this is screen sharing on declaration level). That would be a useless limitation.
So, the meta-types are reduced to Persistent, Temporal and Exception meta-types. It seems that references can go in any direction, independent from the life cycle levels, but downward references act as "template" mechanisms. An Exception may refer to a Persistent or a Temporal entity, and that is a direct instance reference: the actual item can be accessed through the reference. On the other hand, a Persistent entity may contain an Exception, but that is only a template, and is "torn off" from the owner (replicated) when used (updated): the server may contain a "temporal server error" exception with "try again=5 min" attribute; this is mapped to any exception sent from the server. But in this case, the sent exception is not "the same instance", the server setting may be modified, it will not affect the existing instances. The same way: the (Temporal) Location aspect in the (Persistent) GUI declaration may be changed (the next windows will appear on a new location), but this does NOT affect the existing windows. On the contrary: a change in a Persistent Data displayed on multiple GUI panels MUST be reflected in all of them.
