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

[Jecel Assumpcao Jr]

btanksley@hifn.com wrote:
> > [source for Self 4.0 available]
> 
> I didn't know that.  Well, mildly interesting, but I'm not writing a Java
> compiler.  Are the basic algorithms written up anywhere?  Otherwise they're
> close to useless.

There are two PhD thesis which cover most of it, so I would not
expect it to be harder to understand than Xanadu (which, BTW, is
way harder to understand than pure Smalltalk source since it is filled
with tags for translation in C++) or Mozilla. In fact, there was
less documentation about Linux when I first looked at it (though
generic Unix books mostly applied).

> I didn't mean to imply that open source was a bad thing -- but the main
> beneficiary of open sourcing a project is the project itself, not people
> looking for code to borrow.  The benefit is a wider audience of debuggers
> for the project itself.

True - the only real code sharing we have seen so far has been
in component based programming. Even the OSKit is really an
instance of this: glue code around black box components. Of
course, this worked for hardware so I expected it to be a
good thing (I first say this in Apple's Hypercard CMD extensions).

Cutting and pasting of C code won't get you very far.

> > You mean having people store things over the internet instead of
> > local disks? My local ISP has just started a similar service.
> > Given slow modems, I wonder how useful that is?
> 
> No.  If I'd meant that, why would I have suggested that people would need to
> buy more storage space?

Oops... I thought you meant "remote storage space", since that is
what the Xanadu servers got you.

> 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".

> 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).

> 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.

I don't think Xanadu allowed deletions at all. In my current
design for my system, only transient objects are subject to
garbage collection. Persistent object are not. I noticed that
only a tiny amount of information in my disks was actually
created by me (and I have 140MB of saved emails!!). The rest
was created elsewhere and downloaded from CD-ROMs or over the
internet. I could easily remove these "replicas" from my local
disks and would in no way be deleting the objects from the world.
If I focus on just my stuff, it is clear that it will grow much
less than the amount of disk available even if I never throw
anything out (and I buy less disk space than most people I know:
I keep trying to make do with the old 120MB drives I have lying
around instead of buying new ones). So, after struggling with
distributed garbage collection for 14 years I just gave up and
joined the Xanadu club: keep everything.

> > I had tested ZigZag a few weeks ago (it is not in a state that
> > I would pay $25 for it) and found the ideas interesting. I think
> > objects would handle what his cells do pretty well, though.
> 
> Cells and objects are completely irrelevant (a cell IS an object).  Links
> are everything.  I'm not impressed with ZigZag, but you have to understand
> it in order to understand Xanadu.

David Ungar says the same thing about Self: that objects and
object-oriented programming aren't good, but a bunch of linked
objects and how they connect together - that is everything.

I like to "think different" :-), so I liked to play with ZigZag.
But when you think about it, there is no great different between
saying that C3 follows C2 in the "weight" dimension in ZigZag, or
having the relation weight(C2,C3) in Prolog, or have the "weightNext"
slot of the C2 object refer to the C3 object...

> > 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.

-- Jecel