Or, "Effective VOS"...
Use grouping Vobjects
If you have a set of objects that work together to describe an aspect, group them under a grouping Vobject. While it does introduce a small amount of overhead, it will make it much simpler for more than one object to share that group, or to move the group from one parent Vobject to another. An especially good time to use a grouping Vobject is if the group is not strictly defined or bounded, and there could be any number of objects in the group.
On the other hand, you may not want to use a grouping Vobject if you think that different parent Vobjects will want to "mix and match" child Vobjects frequently. In this case, the potential "group" is less unified and may benefit from being broken up into individual objects.
Be dynamic: don't assume children exist; don't always store vobject references
In most cases, it's most useful in the long run to allow any vobjects being used to be dynamically added and removed at run time, and for your application to respond correctly. So unless it's certain that a certain child object must always be present, use a listener to discover it and then act on it. Don't forget to deal with the object being removed as well.
Instead of storing a Vobject for later use, consider using findObject() on the parent to access it at the time it needs to be used (and catch the NoSuchObjectError exception). Or, if you want to store Vobject references (because you have several with the same name, perhaps, or will be accessing it frequently), remember to use a listener to deal with the object being inserted, removed, or replaced at run time.
Instead of writing simple classes with the assumption that it will be created at program start and deleted at program end, write them to be coupled to the lifetime of a child link; when the child is removed, delete the object.
For example, a top level object "T" will have as a child, a container object "C" will have several child properties, "foo", "bar" and "baz".
You could simply check for all of those objects when your program starts up, but this will prevent users from being able to move objects around at run time.
Instead, try this: Write a child listener class to listen to T, and a class that's both a child listener and a property listener to listen to "C" and its properties. When an object is inserted under "T", check if it's named "C". If so, create the "C" listener. When removed, delete that listener. In the "C" listener, when a new property is inserted that is named either "foo", "bar" or "baz", add 'this' as a property listener. When any of those properties is removed, remove the property listener. The "C" listener must also remove property listeners in its destructor. This s
Check the VosToolbox library for classes that help implement common patterns like this.
How to use an object's own message queue to make a "timer"
TODO this would best be implemented if/when some future changes occur to libvos, namely a mechanism to delay message delivery until a certain time, (though you could also trigger message sending from another thread while still handling it in the vobject thread) so either update this or remove it if this future change gets implemented or not:
If you want events to automatically happen to a Vobject at a regular interval, you can use the object's own message queue to implement this while still handling the event within the message queue (rather than in an extra thread). TODO... explain more...
How a client connects to a server
E.g. TerAngreal.
TODO. Include how to deal with factories, user preferences, etc.
Using object factories
TODO: Discuss the use of object factories: When to use them on the server for various types of application purposes and desired results (e.g. games, guided tours with custom experience for each user, etc.) Describe how a client application should make decisions about whether to use a remote site's factory or create local objects, including using templates for the factories, and/or modifying the created objects later. Consider adding this stuff to Creating Interreality later when done.