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.) > 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? Then their positions change... not sure I see the problem... The ParentChildRelation (or whatever its called now) just points to the embedded property that happens to be inside its owner Vobject object, rather than a stand alone Vobject object. Still has a name, position, and the parent vobject can just treat it the same way as the other members of its child list when it comes to ordering and iterating and finding children etc. > Or tries to replace an embedded child? Or remove it? Similar to a normal vobject. The Vobject that owns is still responsible for it and does all work associated with it if some other Vobject has a child link to it. Otherwise, deletes it. I guess Vobjects would also need messages to ask them to create new embedded properties as well, so you could recreate the embedded property. > > * 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. This should be possible, no? The vobject can basically contain Property objects which are capable of handling remote message same as stand alone properties, and give those to the site/host to keep in its list. So it gets a unique identifier, is that hard for some reason? (Or rather than a normal Property, could be a special EmbeddedProperty type that implements the same interface as stand alone vobjects for receiving messages, etc.) 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. But maybe I'm missing some of the issues here... Reed _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
