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. 
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 
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 
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 

> 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 
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 
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...


vos-d mailing list

Reply via email to