M

OJO is a dynamic MASCOT machine and can be configured on the fly. MOJO accomplishes this by holding  all active entity descriptors in an internal repository.

Adding more descriptors to the repository by enrolling new SET documents is a two step process. First, the machine creates a temporary repository to hold the descriptors from the newly read and parsed SET. If there are errors the process stops here and the central repository is not updated. On the assumption there are no errors, the machine merges the central and temporary repositories and removes the temporary version. This 2 stage process minimizes the chances of corrupting the central repository and assures its contents are always accurate and up to date. It also makes it possible to snapshot machine state at any time by dumping a consolidated SET document that can be reread as part of system recovery process.

While merging the temporary and central repositories MOJO enforces some simple rules. If an entity is defined more than once (this is most applicable to subsystems and devices since they are named globally) the last definition wins; all others will be discarded. The only exception to this rule is the global subsystem which is built incrementally. Any SET document can define a section that contains entries for entities to be incarnated in the global subsystem. By definition, any entity placed in the global system will be incarnated immediately; MOJO ensures this by guaranteeing the incarnation of newly enrolled entities before the enrollment process competes.

Any application can take advantage of this behaviour to bootstrap itself. The general strategy is to write your application with a bootstrap activity or subsystem and place this entity in the global context. The effect will be that when the SET document is enrolled the bootstrap entity will be incarnated and can carry out any other initializations. Please refer to the examples and source code for more information on this technique.