Menu

#2 write white paper on presentation/UI layer

open
nobody
None
5
2000-06-02
2000-06-02
Lucas Gonze
No

The plan for UI is that there will be separate controller apps responsible for
1) informing the WOS node of its context; for a node acting as a local program this means to tell it where to find data serialized from one invocation to the next.
2) starting and stopping the node
3) confirming that the local environment is able to support the node; doing dependency checks on startup; setting classpath properly before kicking off.
4) setting variables like max connections, default TTL, etc.
5) telling the node what function handlers to load on startup

The only config data to be included with the node itself is a certificate for the controller. There is an open question of how to allow the node to find this config data without needing to read from some specific location on disk. [this matters because WorldOS, the metaphorical one, has only a hazy understanding of file hierarchies and such. The reference implementation is intended to thrive by using the base rules as leverage, rather than wither because of misguided attempts to ignore the base rules. FWIW this principle is the cause of many of the odder aspects of the refi].

I am leaning towards putting a class within the classpath, so when the node starts up it calls Yourclass.getAdminCertificate(). The reason I find this acceptable is that a working classpath is already a requirement for interfacing with the local environment. The downside of this is that the local interface class would have to be compiled locally... this needs more thought.

Within the refi as shipped the only function handler available at startup would be the function handler loader.

Discussion


Log in to post a comment.

MongoDB Logo MongoDB