gmane.comp.lib.vos.devel

s5 properties again

Some ideas for a new design for properties.

Replace the vobject "child list" with a "property map".  A property is a 
slot that holds some value, which can be a basic type (int, string), a 
compound type (struct, array or map) or a reference to another vobject.  
Reflection permits iterating over all entries in the property map.

Unlike links in the child list, the order of properties is not 
significant, and two properties of the same name are not allowed.  Where 
order is important, data can be stored in an array property.

Paths are still available.  For example:

/vos/Namespaces/core/Types/String

Where
"vos" is a vobject
"Namespaces" is a map of names to vobject references
"core" is a reference to a particular vobject
"Classes" is another map, part of "core"
"String" is a reference to another vobject

Another example:

/scene/objects/_2/position/x

Where
"scene" is a vobject
"objects" is a list of vobject references
"_2" is the reference at index 2 in the list

(Continue reading)

headers

Lalo Martins | 3 May 11:00

Re: s5 properties again

Also spracht Peter Amstutz (Thu, 01 May 2008 22:31:03 -0400):
>  - It's going back to the drawing board (again) (not completely, but it
> does mean some work redesigning the VOS APIs, the XOD format, changing
> the code generator, etc)

For me this kills it.  How much do you estimate it would set you back?  
And is what's wrong with the current design serious enough to justify 
this time?  A good yardstick for that is: is the new design sufficiently 
better that, if you stop now to implement it, you'll still have gone as 
far by end of this year as you would if you don't?

*IF* you really think it's worth it, then I'm willing to discuss the 
details; but I think before we even get to that, it would be good to 
discuss whether a project of this magnitude is worth considering at all.

best,
                                               Lalo Martins
--

-- 
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
                           -----
                  http://lalomartins.info/
GNU: never give up freedom              http://www.gnu.org/

headers

Peter Amstutz | 3 May 18:19

Re: s5 properties again

On Sat, May 03, 2008 at 09:00:30AM +0000, Lalo Martins wrote:
> 
> For me this kills it.  How much do you estimate it would set you back?  
> And is what's wrong with the current design serious enough to justify 
> this time?  A good yardstick for that is: is the new design sufficiently 
> better that, if you stop now to implement it, you'll still have gone as 
> far by end of this year as you would if you don't?

I know, that's why I wanted to get input from everyone first.

The original reason I even got on this track was that in the process of 
designing serialization and marshaling for getters and setters, I 
realized the old tentative design created a number of problems I 
couldn't resolve, which caused development to hit a brick wall.  I 
actually have a long email I wrote last week outlining the problems in 
great detail, I didn't send it then but I will do so now.

> *IF* you really think it's worth it, then I'm willing to discuss the 
> details; but I think before we even get to that, it would be good to 
> discuss whether a project of this magnitude is worth considering at all.

Well, at the moment I'm in a bind one way or the other, since I can't 
proceed without resolving this impass.

--

-- 
[ Peter Amstutz ][ tetron@... ][peter.amstutz@...]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

(Continue reading)