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

[Peter Amstutz]

Well, I was thinking that you have the (simplified) tuple (id, version).  
You can't write to an older version, since that's rewriting history.  The 
kind of transparent branching like you're talking about seems a bit 
excessive, although I was thinking about "alias" vobjects that would just 
be a transparently reinterpreted pointed to another vobject, which could 
point to a specific version...  This quickly starts to get complicated, 
though.

The way I see it, if you write to a vobject, one of three things can 
happen (when you replicate the vobject, it has flags telling you which 
one to use):
 (a) always send the request and wait for the reply before committing the 
change
 (b) send the request, apply the change optimisticly, but allow that the 
change could be rolled back
 (c) apply the change locally and don't send anything 

(these cases should look familiar, I think replication of value is 
basically the same as the replication of computation question)

We do need to distinguish between local changes and "official" (digitally 
signed) changes.  This is pretty easy, though, by clearing the digital 
signature or setting some sort of "dirty" flag.

On Tue, May 08, 2007 at 06:13:21PM -0400, Reed Hedges wrote:
> > > 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.  
> 
> The example I was thinking of is this:
> 
> Property P has versions P.1, P.2, P.3.  If you have a normal reference
> to P, you get P.3, though you know it just as P.  If you write to P, it
> creates a new version, P.4, but P (being the "current version") is
> transparently changed to P.4.  But if you have a reference to
> P.2, and you write to it, resulting in a new version P.2.2, it appears
> to you that the write didn't work, since you're still looking at P.2.
> So P.2 needs to be an alias for "most recent version of P.2" in the same
> way that P was.  P.3 is then also an alias for "most recent version of
> P.3", but P.3 doesn't have any derivative versions, so it's just P.3 (or
> call it P.3.0 or something).
> 
> Reed
> 
> 
> _______________________________________________
> vos-d mailing list
> vos-d at interreality.org
> http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


-- 
[   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/7e752f20/attachment-0001.pgp