VOS data model.

(Note: some of this is implemented, but some ideas particularly the transaction
concept is not ready yet.)

Vobject is a collection of properties (string -> value map)
Property values can be a number, string, or arbitrary nested vectors and maps.
Special properties are:
  __vobjectId__     the unique key on the vobject manager
  __vobjectType__   datatype hint
Can also create symbolic links using a map with a single key:
  __vobjectLink__   maps to the name of the object to link to
(this could be an arbitrary path another property)

Vobject Manager is the root that holds the vobject id -> vobject map
All changes are handled by the vobject manager
Changes are transactional.  A transaction consists of N orthogonal changes
(adding/setting/removing vobjects and properties).
Completion of a transaction bumps the version from M to M+1.

Changes are proposed against a specific version.
Changes can be accepted against versions prior to the most current provided that no
conflicting changes have been made between the target version and current version.
Conflicting/rejected changes bounce and the agent that proposed the change
can retry (or not) against the most recent version.

Hooks will allow the user to provide conflict resolution polices 
and game (or business) rules which are able to reject changes that violate
the rules.

Transactions can be clocked, in the sense that there is a transaction window open for 1/Nth of 
a second, all change requests received in that window are commited as part of the transaction
for that window (this is what the Simulation Concurrency.txt document means when it refers 
to "frames").

Vobject manager also manages event subscriptions.  Completion of a transaction sends
out change notifications to interested parties.

Synchronization granularity is at the level of a whole vobject.  

Clients can lazy-fetch vobjects as needed or subscribe to live updates to maintain a full site replica.