[vos-d] Van Jacobson: "named data" -- revision control

[Peter Amstutz]

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  ][ 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/20070508/7841108f/attachment.pgp