The client connects to the server, displaying the login interface window.

Entering login information sends a login message to the server, which causes
the server (if it is valid) to incarnate the player in the correct room and
display it.

The server keeps characters in a database, updating them when the player
disconnects (intentionally or not). When the client disconnects, the
associated character disincarnates and is saved to the database. The
database is synchronized to the disk manually, or when the server is shut
down, or gets a sighup. (The server is designed to run on UNIX, if it happens
to work on non-UNIX-like operating systems, this is incidental.)

The database objects are quite smart, able to track changes to themselves
and able to synchronize via the network mechanism message with remote objects.
(There is declarative control over what objects may be synchronized and it 
which directions. For instance, two co-servers may have bi-directional
synchronization on character stats, whereas the clients would have
monodirectional synchronization, receiving updates to the values from the
server.) Probably the database should be integrated into this larger sync
fuctionality? See db.txt.

The server will need a thread for each room, since turns/time is on a per
room basis. There will be a global dispatcher of messages to rooms and the
net class needs to be made able to hand off clients between instances so that
each room can have a net instance.

Maybe have servers operating in a flock of room-based servers? No, WAY too
much overthead, threads only. Maybe do this with stackless. Need to find out
more about stackless.







# Process of dealing with objects
0. Create the object: either make it locally or fetch it from the server.
1. Check out the object.

####################### NEW DB DESIGN ---> see oowriter doc