Whirled Design -*- mode: outline -*-

* Overview
Whirled builds on top of the Presents and Crowd packages and provides a
framework for building a virtual world made up of a node network of
individual scenes. In the abstract, scenes contain only exits to other
scenes and the world is one big directed graph. This is not unlike the
structure of MUDs where one classically thinks of rooms and exits. We've
chosen the term scene to avoid implying that we're indoors.

Whirled provides a means by which clients can move from scene to scene,
and to different locations within the scene (though restricting clients to
movement only to a pre-defined list of locations within the scene is
optional).

The scene information needed by the client may differ from that needed by
the server. Specifically, the server may need only know about exits to
other scenes, whereas the client will need to know how to render a scene
which may involve substantially more information (tile lists for top-down
and isometric renderings or a 3D scene model). To this end, Whirled
provides services for building static scene bundles that can be included
with the client and then updated over the wire if the client enters a
particular scene and needs updated scene information. Using these
services, the world can change and evolve and the client can be sure to
always have the correct scene information. Excessive downloading can be
avoided by seeding the client's scene database with a snapshot of the
system at the time the client is delivered, and subsequent snapshots can
be provided periodically to bring all clients into sync with the runtime
scene database, from which they can then continue to mirror updates as
needed.

* Notes
Scene provider needs to do the right thing when a client requests an out
of date scene. Presently it doesn't handle sending the client the updated
scene data.

Scene manager registers a timer when it becomes empty and flushes itself
from memory after timeout period.

Client should avoid unsubscribing from scene objects straight away so that
it can avoid resubscribing if they bounce back and forth between scenes.

We'll want the scenes to adhere to some sort of hierarchy so that we can
associate properties files with classes of scenes which will be used to
configure the scene managers when they are initialized.

Add code to flush scenes from the client scene manager cache.

We need some mechanism for the scene registry to know which SceneManager
derived class to instantiate. Probably something like
Scene.getManagerClassName() which can be implemented by an application
when it creates its Scene implementation.