quick overview

Here's a quick overview of the top-level architecture:

1. Portal. This is a client side interface. I expect there will be an RMIPortal soon, but right now Portal is implemented by the Main client class. Portal is responsible for creating a new channel for each new client.
   
2. Channel. Currently there is DirectChannel, but what we really need here is a remote interface. A channel accepts user requests and returns the response. A channel is the client's only access to ArkDb.
3. Client. Uses the channel to communicate to ArkDB and formats the responses. There can be text/swing/servlet clients.
   
4. ServerChannel. Doesn't yet exist because of the use of DirectChannel. It creates new sessions when there is a new channel connection and routes user requests and server responses between the client channel and the user interface.
5. UI. The client may request either a UI object or a subclass of same as its user interface object. A client may also switch between UIs, but only one is active for any given session. UIs are threadsafe. They are responsible for the content of the server's response to requests, particularly the header and default body of the display.
6. Session. Stateful. Manages a stack of evaluators (filters) for processing user input.
7. Evaluator. Stateful. Parses user input, invokes commands and responsible for managing dialogs with the user.
8. Command. Threadsafe. Invoked with a command line containing any arguments together with an optional document from the client. Updates ArkDb and requests displays to be processed.
9. Displays. Formats data from ArkDb. Invoked only at the discression of the UI when a command requests it.
   
10. Rolons. Persistent application objects residing in ArkDb.

That's a fair amount of architecture, but breaking code into smaller roles does seem to reduce the size and increase the clarity of the program when the interfaces are appropriate.

Bill