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 ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [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 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
