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

[Jecel Assumpcao Jr]

btanksley@hifn.com wrote:
> > 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.

While I am pretty sure it was a planned feature, my impression
was that the released code doesn't yet support mutiple servers
with overlapping data. You can always try Lotus Notes :-)

> > [confusing version names example]
>
> No, because the servers each have their own tumblers.  You can even
> cross-link the stuff between the servers.

and shapj@us.ibm.com wrote:
> It's not a problem.  The labeling of versions is an artifact of the user
> interface.  Internally, the versions are distinguishable and unconfused.  I
> think you are confusing the labels for the versions.

Right - we are talking about three distinct objects with universal
identifiers obj1, obj2 and obj3 or serv1:obj1, serv1:obj2 and
serv2:obj2.

But there is a namespace service somewhere to map name "2b7" and
"2b8" to these objects. Note that we are talking about the OSMIC
prototype version management system, which doesn't allow multiple
servers, so this is not a practical problem yet. I am trying to
figure out how to merge the name spaces of serv1 and serv2.

martelli@iie.cnam.fr wrote:
>   Jecel> I like to "think different" :-), so I liked to play with
>   Jecel> ZigZag.  But when you think about it, there is no great
>   Jecel> different between saying that C3 follows C2 in the "weight"
>   Jecel> dimension in ZigZag, or having the relation weight(C2,C3) in
>   Jecel> Prolog, or have the "weightNext" slot of the C2 object refer
>   Jecel> to the C3 object...
> 
> Considering available OOL, this makes a very big difference, since the
> slot belongs to C2. Adding another relation requires that you modifiy
> C2, and that's not possible at run-time for most OOL. Creating a new
> relation that refers to C2 does not have this problem.

In Self I can just write:

  (reflect: c2) at: 'weightNext' PutContents: (reflect: c3).
  (reflect: c3) at: 'weightPrev' PutContents: (reflect: c2).

This will change the "type" of these two objects and link them
together. This isn't exactly a high speed operation, but it
probably fast enough to be practical (specially if I use
temporary variables to avoid doing each "reflect:" twice) and
the compilers will be able to generate very fast code for the
more common operations.

-- Jecel