Cher Mk3 Design -*- outline -*-

* Why Cher?
The basic function of this layer is to allow the sharing (Cher-ing) of
information among different nodes in the network. Plus, I don't think Cher
has ever had a software system named after her and it's high time. Imagine
Cher as the social lubricant that allows the party goers to communicate.

* A note on thread-safety

Distributed objects are designed only to be accessed from one thread. On
the server, there is a distributed object dispatch thread on which 95% of
all activity takes place anyway. It would be questionable to require that
thread to access distributed object members through synchronized members
just so that the few places where it is convenient to access dobjs off of
the dobjmgr thread are simplified. Instead we've opted for the performance
and care must be taken not to access distributed objects outside of the
dobjmgr thread.

Events can be generated from any thread, but values should not be read
from the distributed object on other threads because they are subject to
change at any time and could be half changed when some other thread goes
to read them.

On the client, care is taken to combine the AWT and dobj threads so that
life is simple from a synchronization standpoint. None the less, the same
care should be taken when other threads are introduced (IntervalManager
for example) not to read values from a distributed object on those other
threads.

This is easy enough to do. Simply copy the values you care about out of
the object before passing the information on to another thread (take care
to copy non-primitive values like arrays and OidLists). If you find the
need to fetch values from a distributed object after another thread has
already started, you'll just have to rethink your approach.

* Client components

** DObjectManager
Manages object proxies; converts value change requests into events,
forwards them via the iomgr; dispatches events on incoming queue; reaps
proxies when last subscriber goes away

** UI (AWT/Swing)
Standard AWT/Swing UI

** UI (Controller)?
Provides a paradigm of controllers and commands; code can post commands
back to the controller queue for later execution; UI elements structured
to automatically generate commands; will probably opt not to use this in
favor of Swing's built-in paradigms

** I/O Manager
*** Reader
Reads incoming data from the socket; decodes messages; posts events to
domgr queue; notifies object subscription penders (this should be done
asychronously)

*** Writer
Encodes object subscription and event forwarding requests; writes them to
the outgoing socket

** Client object
Informs exo-client about connection state changes; provides interface to
connection + authentication (logon) and disconnection (logoff); provides
access to omgr and client dobj

* Server components

** Connection Manager
Listens on accepting socket; creates and manages connection objects;
informs connection observer of state changes; handles all network traffic
on own thread; 

** Auth Manager
Processes auth requests on own thread; uses pluggable Authenticator to
perform actual authentication; 

** Client Manager
Registers with connection manager; manages authentication; maps
connections to existing client objects or creates new client objects for
newly connecting clients;