Let's see if I can clear up a few things... Bear in mind that the design is still evolving in my head :-)
a) From the perspective of VOS, which is concerned with synchronization, the most important purpose of versioning is so you have a basis for deciding whether your replica A' of vobject A is current or out of date. Being able to record changes and go back into the history is just a nice side effect. b) Each vobject would be versioned separately. The child list is part of the versioned state, but a change to a child vobject should not affect the version of the parent. One exception: embedded children (property fields) do affect the version. c) The big picture I'm going towards here is that remote vobjects, caching, scalability/load balancing and the kind of broadcast routing Van Jacobson talks about are all basically cases of replication. If the VOS design can unify these cases under one general solution then we've won. I need to develop the idea more, but I think one key idea is relaxing the idea of a "site" so that it doesn't have to be tied to a specific host. I had already decided that sites would be identified by their public key, so that messages distributed by the site are self-verifying (by checking that the digital signature matches the site id). This means if you want to query a vobject, any replication -- the actual host site, a local cache, a third party -- can answer, and you can check that the answer did in fact originate from the site. What's really interesting is that this means the authority to publish changes to vobjects rests in who has knowledge of the private key that corresponds to the site's public key. If you wanted to do load balancing/clustering, you could share that private key among several trusted hosts, any one of which would be able to issue official state changes for vobjects on that site. I should point out that in the most common case, hosts will be in direct contact with the actual site, and receive messages published from the site directly, so it's not any different from the way things work now. Getting back to Kao's question (which I've wandered quite far away from), as noted the synchronization principals in the system are the site and individual vobjects. I don't see how cycles and bounderies between subgraphs factor into it, except perhaps in the initial phase of determining the specific subset of vobjects on the site you're interested in. On Wed, May 09, 2007 at 11:45:50AM +0200, Karsten Otto wrote: > Well, Lars' suggestion of versioning only "interesting" parts and > your suggestion of horizons seem reasonable, but I don't think we > have the basis for this in VOS. A vobject usually cannot live as > isolated entity, but *requires* a number of relations to child > vobjects to make sense; thus any user-percievable "world object" is > actually a subgraph of the overall world graph. > > The problem is delineation: It is not clear which subgraphs represent > independent "world objects", or if there is even a distinctive > decomposition. For example, two objecs may share a texture - which > vobject does it "belong" to? If you change one vobject, do you > include the texture in the version? Where do you stop following > relational links? I don't recall if there is any prohibition in VOS > against cycles in the graph - I think there isn't - so matters become > even more complicated. > > The only separation I currently see in VOS is the relation between > the site vobject and its children, but even here it is not clear > which children represent aspects of the site itself, which are > scenery, and which are avatars. > > Any suggestions? > > Regards, > Karsten Otto (kao) > > > _______________________________________________ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ 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
