On Tue, May 08, 2007 at 03:56:07PM -0400, Reed Hedges wrote: > > There are lots of ways to do version control in VOS-- we already have it > partly implemented. One important thing that we need to decide is how > to expose particular object revisions to remote sites. I think we need > to be able to refer (by URL) to both the current version, or to any past > version (in all ways as a normal vobject, with all interfaces, etc.)
Right. I think the key is going to be to start thinking about remote vobjects as simply replications of the actual vobject, and which means those replications use the same system to be stored on disk (cached) or passed around. The vobjects just happen to be associated with a different site; but I think it's worth considering relaxing the concept of "site" to its simplest form of "a set of vobjects covered by a common public key", and that sites have a standard (replicated) vobject that contains its contact information. Then if you ask one host how to get in contact with some other site, it gives you that replicated contact information. Another crucial aspect of replication that keeps coming up is computation: I think when we replicate vobjects, we'll need to indicate whether it's computation can be replicated as well. As I stated in my previous email, this could be "don't replicate" (can't do anything with an object without contacting its original site), "predictive replication" (both contact the server and do the computation locally) or "full replication" (always run it locally and don't contact the server). I've been thinking about replication a lot due in part to reading about how Croquet works. However, where Croquet assumes a totally deterministic system (which makes replication of computation easier), I want to allow for a little more slack, provided you always have the ability to bring everything back in line. This is worth thinking about more, since it has pretty fundamental design implications, but is also central to how remote vobjects work, to caching, to versioning, and to scalability across multiple nodes. What's interesting is this is a shift not in how vobjects themselves work, but in how they move between hosts. I also think that for all this seeming complexity, that in fact in the cases where it matters, most of that complexity shakes out and it can still be very efficient. > This means that if that version object is mutable, i.e. a not read-only > property, we need to also have branches in the version history, and any > reference to a past version of a vobjcet is really a reference to "the > most recent version in the branch rooted on this object, which if there > is only one version in the branch, is the same as the root object" [if > that makes any sense]. I don't understand. Lalo will undoubtedly correct me if I'm wrong, but it seems to me what is most important is linear version history leading up to specific object. Branches mark the point at which item Y diverged from item X, which in this case would likely mean item Y would be given a new vobject id, or possibly have the same id but located on a new site. We could save the fact that it branched as metadata (maybe a core:branch-history vobject type), but it shouldn't be part of the fundamental vobject id. I should point out here that you don't actually *have* to keep a version history around, that's just a nice side effect. So long as you bump up the version number with each change (and timestamp, and regenerate the digital signature, etc) you have a simple way to compare your vobject replica with the master version on the site to decide if you need to synchronize or not. -- [ 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 [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
