Whirled Design -*- mode: outline -*-

* Overview
Whirled builds on top of the Cocktail platform 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
Scenes map to places.

Scene manager extends place manager, handles scene related stuff.

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

Location manager is used to navigate between scenes on the client;
location services will need extensions to support delivering scene version
with moveTo request and serialized scene data with moveTo response
(desirable to avoid extra server round-trips).

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