On Thu, Apr 24, 2008 at 11:39:01AM -0400, Reed Hedges wrote: > > Properties as child vobjects is too useful to get rid of I think. If > properties are always embedded, then you can't have two vobjects share > a property, which is one of the most important features of VOS. They > also can't be remote for whatever reason, and you can't use the normal > Vobject/Metaobject/Component stuff to create a specialized kind of > property. These are also critical features. > > I'm still not clear on why properties as some kind of embedded > children won't work. Can you give an example? Yes, the parent object > has to keep track of which children are embedded and which aren't, and > there's overhead there, but it shouldn't be that big of a deal, > especially since in most cases they will be a small bounded set of > known properties (not a huge list). You would have to have some proxy > fake vobject to give to the site/host for remote objects to contact, > of course, but is that also too much? What I liked about your > embedded-properties comprimise is that it ought to let one switch a > property from embedded to non-embedded transparently. And it's one > less extra thing for applications/tools to interact with -- another > great thing about VOS we should preserve (small number of basic > operations for apps and programmers to worry about.)
The gist of the problem is that my goal for "embedded children" was ideally that there would be zero overhead. For example if you have a 32 bit integer property, the underlying storage (in the C++ class or whatever) ought to only require exactly one 32 bit integer -- four bytes. The parent vobject handles messages to/from the embedded property, and synthesizes a stand-in pseudo-vobject on demand if the embedded property needed to be accessed independently. In other words, rather than having an entry in the child list specifically for the embedded property (which is redundant, if you have 100,000 instances of that vobject type, you need to have that child entry repeated 100,000 times), accessing the property is handled through reflection and code generation. Unfortunately this approach raises a number of design questions that I'm not entirely happy with. 1) The whole point is for embedded children show up in the child list. If the embedded children doesn't have a position assigned to it (zero overhead, remember) then what position does it show up at? 2) If there are multiple components, what is the best way to merge or concatinate the embedded children lists? 3) What is the least supprising behavior when a user tries to remove, replace, or reorder an embedded child entry? 4) What vobject identifier is assigned to the embedded child? Is it based on the parent vobject id, or should it be assigned entirely independently? 5) Ideally when serializing a vobject, embedded properties should be stored as efficiently as possible. In addition, my thinking was that embedded properties would correspond to database columns in a future object/relational mapping scheme. If embedded properties are treated like vobjects, that likely adds a layer of complexity beyond just storing data. Now, I'm not saying this design can't be made to work. However, the most obvious solution means adding special "embedded child" entries to the child list of every vobject of a particular type. Meaning, if an vobject type is used 100,000 times, there are 100,000 child list entries which are mostly redundant, but have to be there just in case... > Basically, we just need another layer in the type hierarchy, in a > sense. You have basic Vobject-like things that sites/hosts (not sure > which) can deliver messages to and which can send messages, and which > have URLs and can be linked to by Vobjects. Below that are Real > Vobjects and Embedded Properties. Embedded properties are deficient or > special-case Vobject-like things in that they are simply missing type > extensibility and children and other features that real Vobjects have. > They can be very simple C++ objects just holding their data buffer, or > perhaps just a reference to their "owner" vobjects which hold their > data for them, if that is more efficient. I see. You're thinking of the s4 design where properties == vobjects, therefore s5 embedded properties == lightweight vobjects. That's true, to some extent, but the goals were also to have zero (memory) overhead beyond the storage space for the actual data, and to have a more straightforward data model of vobject state so that serialization and persistance can be implemented efficiently. So my concern is that the old vobject child list model may be the best way to achive to these goals, so it is at least worth examining the issues and alternatives before plowing ahead with a complicated compromise solution. On alternative I am considering would be to change the child list from an associative array to a property map. Entries in the map could be either embedded properties or dynamic properties, but since it would be a map there wouldn't be any ordering issues. Ordered lists (necessary for applications like hypervos) would still be possible, but would stored as properties (so you would have a property would be a list of outgoing links.) In this scheme one could share the same value among multiple properties could be acomplished by "overriding" the embedded property with a dynamic property linking to the shared value. This idea is still a little half baked, so I will follow up with examples when I have nailed the design down a bit more. [ 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
