gmane.comp.lib.vos.devel

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

(Continue reading)

headers

Reed Hedges | 13 May 22:29

Re: 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,

(Continue reading)