headers
Peter Amstutz | 23 Apr 06:50
Picon
Favicon

s5 vobject properties

Things have been quiet lately, but I assure you, we are still working!

Anyway, something I've been mulling over --

One of the planned changes in the design of s5 as compared to s4 is the 
integration of plain-old-data properties as part of the vobject class 
definition.  In s3 and s4, property data (simple stuff like integers, 
strings, position vectors, etc) is stored by special vobjects with a 
special "property" type.  This has some nice advantages in that the 
properties describing a vobject are just child links to other vobjects, 
so browsing and editing vobject structures is very straightforward.

The disadvantage of this scheme is that it is very inefficient.  It 
results in vast amounts of overhead for storing what amounts to a field 
in a data structure, and it also introduces coordination issues among 
property vobjects that should otherwise be logically tied closely 
together.  It would be much better (more memory efficient among other 
things) to be able to store simple data as part of the vobject class 
directly.

So, for s5, the idea I originally had was to try and meet these goals 
halfway and have "embedded children".  These would be sort of "virtual 
vobjects" (hah) that would appear to be child vobjects, but be managed 
entirely by the parent vobject they are embedded in.  This would combine 
the benefits of the "everything is a vobject" abstraction with the 
advantages of storing things more efficiently.

As always, though, the devil is in the details:

 * For the "embedded child" concept to work (or even make sense), these
(Continue reading)

Permalink | Reply |
headers
Reed Hedges | 24 Apr 17:39
Picon
Picon
Favicon

Re: s5 vobject properties


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
(Continue reading)

Permalink | Reply |
headers
Reed Hedges | 24 Apr 18:24
Picon
Picon
Favicon

Re: s5 vobject properties


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

class Entity 
{
  handleMessage(); 
  set<Entity*> parents;
  string url;
}

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

class Vobject : Entity 
{
  list<Link> children;
  vector<EmbeddedProperty> embeddedProperties;
  list<Component*> components;
  etc.
}

class PropertyCore 
{
  read();
  write();
(Continue reading)

Permalink | Reply |
headers
Peter Amstutz | 25 Apr 05:20
Picon
Favicon

Re: s5 vobject properties

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,
(Continue reading)

Permalink | Reply |
headers
Reed Hedges | 25 Apr 14:48
Picon
Picon
Favicon

Re: s5 vobject properties


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
Permalink | Reply |

Gmane