[vos-d] s5 progress and design

[Peter Amstutz]

On Wed, Dec 05, 2007 at 11:43:47AM +0100, Karsten Otto wrote:
> Hi Peter, some questions/comments from the top of my head:
> 
> What does importReplica() imply exactly? Is this just loading a local  
> copy, or does it include contactig the remote site and merging updates?

The idea is this is actually a copy of (a subset) of the site at some 
revision.  You're loading from this copy, which might have been 
retrieved from the server, or maybe from somewhere else.  After loading 
the replica, you might contact the server to find out if anything has 
changed between the revision you have and the most recent revision.  It 
is heavily inspired by distributed version control, although the focus 
is more on disseminating signed updates from a central site than on 
branching and merging.

> The property lookup example seems a bit verbose for a task that I  
> assume will be quite frequent... Wouldn't this be wrapped into some  
> MetaObject method getOccurrence() : String?

Yes, that's exactly what it does.  The code generator provides those 
accessors.

> The interface description seems to slowly approach WSDL Land... Have  
> you considered some shorthand syntax to free a developer of all the  
> XML clutter? Or do you envision GUI-based development tools for this  
> (really the only way to live with WSDL if you have to use it)?

I agree.  It's not high on my own list of priorities, but this would be 
a good, easy project if someone wants to help out. (hint, hint)

> The fact that you need a *site* for an interface description seems  
> pretty strange to me, even though I am aware you are re-using the XOD  
> stuff for this... but do developers really have to generate a siteID  
> key for every interface they design? Rather pointless, isn't it?  
> While it may make sense to actually have the OTD vobject structure  
> linked on a site that uses it, you usually don't know the target site 
> (s) at development time. Maybe modify the XOD parser to consider the  
> site/siteID optional, or use a shorthand syntax in the first place :-)

That's because the site is actually part of the logical namespace.  What 
this means is (site id shortened for brevity):

  vos:00112233/OTD/vos/FooClass 
is entirely different from
  vos:44556677/OTD/vos/FooClass

Because the class vobject itself is a different vobject located on a 
different site.  This means an object that implements the first 
"FooClass" is not necessarily compatible with the second "FooClass".

Another way of thinking of it is that the act of defining and making 
available the interface definition is the same as publishing any other 
type of data via VOS.

> What exactly is the site revision? An interface version in this case?  
> What does this mean on a real site, i.e. virtual world? Does it  
> change with every child addition/removal, or even every nested  
> property value change? If so, what is the datatype, and what to do  
> when it wraps?

The exact sematics of revision control still need to be decided, but 
generally speaking, every discrete change would increment the revision.  
The datatype will be a 64-bit long integer, so we don't need to worry 
about it overflowing in our lifetimes :-)

> Regarding naming, there seem to be MyType, MyTypeWrapper,  
> MyTypeImpl... what exactly is the difference between the three? The  
> old distinction Interface, RemoteType, LocalType does not quite seem  
> to fit anymore in the way you use the new code.

Well, s4 never really had a concept of abstract interface except for the 
Vobject class, but it is a standard pure-virtual interface-oriented base 
class.

"LocalType", being the concrete implementation of a component 
(metaobject type), is most closely related to "MyTypeImpl".

"RemoteType" is most closely related to "MyTypeWrapper" (since the 
wrapper will handle marshaling and unmarshaling).  Wrappers are 
different since they are (a) a very lightweight temporary stack-oriented 
class, not mananged by VOS and (b) the wrapper manages access to all 
vobjects, whether local or remote (since marshalling is also required to 
call between threads).  I've come to the conclusion that allowing 
customized stand-ins for remote objects is a bad thing, in general.  It 
should be handled at the application level.

A large part of the change in terminology is due to an overall change in 
thinking.  The idea is to not differentiate between local and remote 
objects per se, but have "objects than I can change" and "objects I need 
to talk to someone else to change".  Hence the notion of our local copy 
of such objects being a "replica", and if we know our local copy is up 
to date (by checking revisions) then it is trivial to service read 
requests using the local copy.

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[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 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20071205/b781d0ee/attachment.pgp