open source, xanadu, persistence and other things (was: Udana x ?)

[btanksley@hifn.com]

> From: Jecel Assumpcao Jr [mailto:jecel@merlintec.com]
> Subject: open source, xanadu, persistence and other things 

> btanksley@hifn.com wrote:
> > > [source for Self 4.0 available]

> > As a matter of fact, networked computers pose a VERY 
> > difficult challenge to
> > my idea of how to best use Xanadu -- when I write an essay 
> > I don't care
> > which disk it's stored on (with the exception of removable 
> > media), but I DO
> > expect it to still be where I put it if the network's down. 
> > I'm not going
> > to try to solve that until I get a prototype.

> Xanadu was intended to be a highly available system through 
> replication.
> The Coda File System people worked to the problem of intermittent
> network access with their "hoarding algorithms".

Perhaps that'll be useful for me.  I didn't know that Xanadu supported much
replication; I'll have to check that out too.

> > The basic idea is that each time you create something on 
> > your computer, you
> > produce a single object.  If you later enlarge that creation, you've
> > actually created another object which transcludes your 
> > original creation.
> > There's no such thing as object deletion; objects go away 
> > when nothing's
> > referring to them anymore.  Just like the name 'unlink' in Unix.

> The second object refers to the first, so it must exist for as
> long as the second one does (or at least the parts of it that
> were transcluded must continue to exist, which in Xanadu means
> the whole object).

Exactly -- although it *might* be possible to run a compactor which
collapses all such redundancies and unneeded links.  Maybe.  I wouldn't
bother to write any such thing, though -- it'll probably wind up being
something like tabnanny in Python, written only to soothe the fevered
imaginations of people who never use Python.

> > You can access any version of any document this way, unless you've
> > deliberately deleted it.  Even versions you've undone.  
> > Even versions you've
> > typed over.  Yes, it'll get cluttered.  I don't know how 
> > cluttered; even GC
> > won't solve everything.  The user interface will have ot 
> > chronological.

As an example of a chronological user interface, take a look at Lifestreams.

> > > The version control system has a nice naming scheme, but wouldn't
> > > work in a distributed environment.

> > Why not?  That's what it's made to do.

> If you have a version 2b7 and you modify it, then you have 2b8. If
> another person makes a change to 2b7, they will create 2b7a1 (I
> really liked this idea, which is a kind of tumbler space). As long
> as there is one server, this central state is no problem even is
> the two users are accessing it remotely. But in a truly
> distributed environment you might need to have two, replicated
> servers. If each user is connected to a different server, then
> both will create different versions labeled 2b8, right? This is
> the kind of thing I am trying to solve.

No, because the servers each have their own tumblers.  You can even
cross-link the stuff between the servers.

> -- Jecel

-Billy