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 ][ [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
