[vos-d] s5 vobject properties

[Peter Amstutz]

Things have been quiet lately, but I assure you, we are still working!

Anyway, something I've been mulling over --

One of the planned changes in the design of s5 as compared to s4 is the 
integration of plain-old-data properties as part of the vobject class 
definition.  In s3 and s4, property data (simple stuff like integers, 
strings, position vectors, etc) is stored by special vobjects with a 
special "property" type.  This has some nice advantages in that the 
properties describing a vobject are just child links to other vobjects, 
so browsing and editing vobject structures is very straightforward.

The disadvantage of this scheme is that it is very inefficient.  It 
results in vast amounts of overhead for storing what amounts to a field 
in a data structure, and it also introduces coordination issues among 
property vobjects that should otherwise be logically tied closely 
together.  It would be much better (more memory efficient among other 
things) to be able to store simple data as part of the vobject class 
directly.

So, for s5, the idea I originally had was to try and meet these goals 
halfway and have "embedded children".  These would be sort of "virtual 
vobjects" (hah) that would appear to be child vobjects, but be managed 
entirely by the parent vobject they are embedded in.  This would combine 
the benefits of the "everything is a vobject" abstraction with the 
advantages of storing things more efficiently.

As always, though, the devil is in the details:

 * For the "embedded child" concept to work (or even make sense), these 
"virtual vobject" property fields need to show up in the child list.  Do 
the fields have a fixed position in the list?  What happens when someone 
tries to insert a link in the child list between embedded child entries?  
Or tries to replace an embedded child?  Or remove it?

 * In order to not have to distinguish between an embedded vobject and a 
real one, they need to use the same identification scheme.  Which means 
there needs to be a way to assign or synthesize an identifier which can 
be used to identify the embedded child uniquely from the parent.

 * What happens when a vobject of the same name and same "property" type 
is added to the child list?  Is it added to the list (resulting in two 
fields that seemingly mean the same thing) or is the value assigned to 
the existing embedded child?

I have ideas about how to deal with these various issues, but generally 
they involve adding additional management data around the embedded 
children.  Unfortunately, that would be somewhat self-defeating, since 
the original goal was avoid having any storage overhead and work with 
just the bare field of the parent class.

Because it is so ambigious what the best (or even correct) semantics are 
for vobject properties as embedded children, I wonder if it is best just 
to drop the idea entirely.  Another idea I have been mulling over is for 
vobjects to have an unordered bag of properties.  This would primarily 
be embedded fields manipulated via reflection, but probably also allow 
new properties to be added on the fly.  In this scheme, properties could 
include parent/child links or lists of links, which would likely mean 
there wouldn't need to be a single child list -- although actually, the 
set of properties would be used in a similar fashion to the s4 child 
list, without the strict ordering constraint.

Overall, such a change would align the general VOS data/object model 
much more closely to that of mainstream object-oriented programming 
languages (particularly Python, C#) than it has previously.  In 
particular, the child list in s4 was designed with XML in mind, where 
preserving ordering in tree structures is important.

Thoughts?  To a large extent the "a vobject is a list of links to other 
vobjects" concept is pretty fundamental to s3 and s4 VOS.  On the other 
hand, I've come to the conclusion that it makes an efficient 
implementation very difficult, so it is worth considering other ideas.

-- 
[ Peter Amstutz ][ tetron at interreality.org ][peter.amstutz at tseboston.com]
[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 ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20080423/dd1171ab/attachment.pgp