open source, xanadu, persistence and other things (was: Udana
Thu, 28 Oct 1999 18:41:24 -0700
> From: Jecel Assumpcao Jr [mailto:email@example.com]
> Subject: open source, xanadu, persistence and other things
> firstname.lastname@example.org 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
> 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