Re: [vos-d] s5 vobject properties

[Reed Hedges]

I'm worried about introducing yet more complexity into S5. You know that this is
a big concern of mine.

What is the exact overhead for having entries in the child list for embedded
properties?   You need a contextual name, and you need the object.  The list
itself stores the position value.  The EmbeddedProperty object stored in the
Component could implement the child list entry interface and store its own
contextual name (which would be constant for each kind of embedded property), 
so the only overhead would be the pointer to the EmbeddedProperty object in 
the list.  This is greater than zero, so it wouldn't be zero overhead, but 
it would let you treat properties and children in the nice and flexible way,
and it's only a pointer's worth of overhead.  Or it could be an index into
something else instead of a native pointer and we could cap it at 32 bits 
or whatever if you're really trying to shave bits off there.

Reed


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

Re: [vos-d] s5 vobject properties

[Reed Hedges]

In other words, I sort of imagined it like this:



class Entity 
{
  handleMessage(); 
  setEntity* parents;
  string url;
}

class Link 
{
  string cname;
  int pos;
  Entity *child;
  Entity *parent;
}

class Vobject : Entity 
{
  listLink children;
  vectorEmbeddedProperty embeddedProperties;
  listComponent* components;
  etc.
}

class PropertyCore 
{
  read();
  write();
  dataBuffer;
  etc.
}

class EmbeddedProperty : Entity, PropertyCore 
{
  Vobject *owner;
}

class PropertyVobject : Component, PropertyCore
{
}


class Site {
  setEntity* entities;
}



So if a host or site has entities foo, bar, baz, you can send messages to
vip://site/foo, vip://site/bar, vip://site/baz, and they could be vobjects or
embedded properties.  An Entity is basically something that can be linked to
and can receive messages, so it includes both embedded and non-embedded
objects.

I know this is simplified but does this make sense?

Reed



___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

Re: [vos-d] s5 vobject properties

[Peter Amstutz]

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