framework architecture overview

Still things to do before I'm done with the architecture, though I've made a stab at cleaning up variable names. Time and past time for an overview of the architecture, mm?

1. clients

There can be any number of different kinds of clients. Direct clients are part of direct portals. But there could be swing clients, web servers, thin python clients, or even other web services.

2. portals

A portal knows how to interface with the client. There is already a single user direct portal, but there could be SOAP portals, RMI portals, etc. And a good portal knows nothing about the client except how to communicate with it--user displays are passed as events which the client is responsible for converting into swing objects, html, etc. (Direct portals being simple and fully integrated with the client, they just know too much!)

3. user interfaces (UIs)

A portal can have any number of different kinds of UIs, and typically a user will be able to switch between them at the command prompt. But for each active session, there is one active UI object.

UIs are responsible for soliciting appropriate display events and passing user input to the session object. UIs are pretty much stateless except that they are tied to a user and to a session object.

4. Session objects are responsible for all session state. There is one per active session. However, the session object also maintains a stack of user input evaluators which maintain additional (conversational) state.

5. Evaluator objects manage a conversation. The initial evaluator which resides at the bottom of the session's stack of evaluators is the command evaluator, which process commands. Evaluators communicate with the UI via the prompt.

6. Commands are thread-safe. There is one object for each command. Commands produce errors, update the ark database, push evaluators on the session's evaluator stack, and request displays.

7. Displays are invoked by the UI, sometimes, after a command which requested it completes. Displays may get state information from an evaluator (the top one in the evaluator stack) or from the session object. Displays generate streams of display events.

8. The ark database provides information mostly to evaluators, commands, UIs and session objects. Only commands and evaluators can update the database.

9. Rolons reside in the database, are operated on by commands and evaluators, and participate in displays. Commands are attached to the various rolon classes. Command scripts may be stored in the content of a rolon which is serving as a descriptor section for another rolon.

The intention of this design is to define an open and extensible application server for personal and collaborative applications, an Agile Wiki. And a whole lot more.