Why the current s5 design for "embedde children" doesn't work...
Background.
A key aspect of the design of VOS s3 and s4 is the parent/child list.
This is an associative array of name/value pairs, where the value is a
link to another vobject. This list of outgoing links plays a key role
in VOS as the primary mechanism of linking vobjects to "properties"
(other vobjects storing values that describe the first vobject) as well
as the overall organization of vobjects into a (mostly) hierarchical
namespace.
Advantages of this scheme (that have gotten us pretty far):
- A naive implementation is very easy, only need the Vobject class.
- Serialization/persistance is pretty easy.
- Introspection of the vobject structure is straightforward.
- Accomodates lists (order-sensitive) and maps (key/value pairs).
- Vobjects can share properties and link to remote properties.
Disadvantages of this scheme (that we learned the hard way):
- An efficient implementation is very difficult. Since properties are
standalone vobjects, there is a great deal of overhead associated with
it: the property vobject has its own child list, access control list,
listener list, etc.
- Because of the overhead, scaling up to large numbers of vobjects
(over 10,000) turned out to be a problem.
- The child list is always order sensitive, even when not required or
desiriable.
- Poorly suited to object/relational mapping.
- Associative array semantics permits duplicate, redundant or
conflicting entries; whether that causes problems depends on how the
child list is interpreted.
- Difficult to deal with the case where one property is dependent or
constrained by another property without exposing a race condition or
requiring additional concurrency semantics.
Original proposed solution.
Originally, the solution was to keep the basic associative array child
list, but introduce "embedded children": child properties which are
actually stored and managed by the vobject that owns them. These would
appear in the child list as normal vobjects, could be individually
linked to and/or replaced by links to remote vobjects. When doing
serialization or persistance, embedded children would be treated
specially and stored efficiently.
Advantages:
- Retains the advantages of the s3/s4 child list.
- Much less (storage) overhead than s3/s4 approach.
Disadvantages:
- Implementation is hairy. Parent vobject must juggle a bunch of
pseudo-vobjects.
- Embedded children still have some per-vobject overhead in the form of
special entries in the child list.
- Leaky abstraction. Embedded children appear to be vobjects, but most
vobject operations (such as having a child list itself) won't be
available.
- In order to save efficiently, serialization/persistance code must be
able to distinguish between embedded and non-embedded children, which
defeats the purpose of presenting a unified interface.
See the thread "s5 properties again" for discussion for a new design
that avoids these disadvantages.
--
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
