Re: [vos-d] s5 properties proposal
We talked a bit on IRC but wanted to respond here too. I think it can be summarized briefly like this, I think: In S4, Vobjects had an ordered list of named child links to other Vobjects, one type of which was a Property. In the proposal, Vobjects have an unordered set of named properties, one type of which is a link to another Vobject. (And properties can be lists or structured records, which could include Vobject links.) I like the benefits of embedded properties, as long as we can still retain or mimic some of the important aspects of Vobjects as well, in order not to limit the usefulness of properties, and also to facilitate transmogrifying a property into a new seperate vobject (using for example the 'overrides' part of your proposal). I think having ordered vobjects is useful. But could live with having ordered property data instead I guess. Properties should still have some kind of type/tagging associated with them (optionally) that could, for example, let programs use extensible API to access them (like Vobjects). For example, could you do the following using the new embedded properties: A property of a certain type has subproperties beneath it that contain the original value translated into other languages or locales. (or are generally speaking alternative versions) You can ignore the translations if you want, but if the property is tagged with has-translations or whatever, and the user has a preferred language, then use the subproperty for that language rather than the default. You could think of various things like this where you want to have the ability to add facets or special meaning onto a property in the same way as you can a Vobject using a Component (metaobject). Or, of course you might just want to have a tag on a property that might have some meaning but which does not imply that any subproperties exist etc. ... Can you walk through how overrides work or how one would replace an embedded property with an override that points to a seperate vobject? Would the new seperated property need to be a subproperty of a vobject? Or could we have a Property type Vobject (like the old kind), with the same or almost the same API as embedded properties? (And then you can link to it directly as a child link.) ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] s5 properties proposal
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
