[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: Presentation on Xanalogical Data Structures

On Thu, 2004-08-12 at 17:06, Steve Witham wrote:
> >
> >Is that drawing one of yours or something you found of the original
> >Xanadu team?
> Mine.  http://www.tiac.net/~sw/2004/08/xanadu has some explanation.

An interesting diagram, and I wanted to be sure to credit ownership.

> >  > 3) I think between bignums and tumblers, there is a middle category
> >>  called multihumbers or something.  These are the transfinite numbers.
> MarkM cleared this up.  "Transfinitessimal," of course.  The fact that
> the arithmetic works the same even with the .0. separators sort of
> surprises me.  How do you make a diff that means "the next document"?
> I guess it has to be specific to the length of the server and author
> fields...but not actually a problem in the context of how these things
> are used in Xanadu.

Yes, _Literary Machines_ emphasized that a diff tumbler has no validity
without being associated with an address tumbler, formed into a SPAN
tuple.  Now SPORGLs (spanning ORGLs) I'm still trying to figure out.

> >[POOM picture] would be useful and I appreciate the suggestion.  I've
> >created a pencil drawing where I bend the tumbler line 90 degrees, so
> >that the V-stream is horizontal and the I-stream is vertical, with a
> >POOM relating the two.
> >
> >http://www.sunless-sea.net/Sketches/stream_sketch.gif
> >
> >I haven't totally figured out -where- the V-stream and I-stream reside
> >on the tumbler line, whether within versions or in the subflooring
> >between versions and documents.
> !?  I didn't think that V and I existed on the same tumbler line!
> I mean, sure they use the same number system, but they are two
> independent coordinates like X and Y.  Or if they are somehow parts of
> the same space (I guessed that maybe the Istream fits in a piece of the
> V address space in order to give both V and I addresses to documents
> orgls), it's best to forget that when you make a POOM diagram.

Ah, yes I and V are both located along the granfilade, hence curving the
the tumbler line to form a 2-d graph.  There is a I-stream subinterval
for each document (or maybe version of document), intermixed with the
V-streams for each version.

> >Yes, I've got that documents are empty POOMs
> Uh...empty?

I mispoke; when a server or user is created, an empty POOM is hung under
their ID along the granfilade.  That POOM is never used, except to
reserve that ID by existing.  And when a document is created, they are
created empty and therefore an empty POOM is hung under there.  But of
course when content is added, it ceases to be empty.

> >  > Anyway, by convention, all the stuff mapped (by a document's orgl) at
> >>  the beginning "half" of a document is
> >>  characters, and all the stuff in the second half is orgls,
> >>  representing links.  Inside link-orgles there can be both characters
> >>  and other orgles, depending on what the link is for.
> >
> >How is the "half" represented?  Literally a '5' digit in the tumbler
> >delineating a separate subinterval or something else?
> The first digit of the position-within-document field.  Literally one
> value for content and another for links, but I don't know what those
> values are.

Oh those.  Yeah in the book they use 1 for characters, 2 for links and
other numbers for 2-d, 3-d, and even DNA.

> >Definitely magic stuff.  One question - in explaining all of Xanadu, say
> >in a book or presentation, would you start at the top and work down to
> >the details, or start with the details and assemble the architecture
> >piece by piece?
> There are different places to call the "top," too: I think the top
> of ISO seven-layer dip is "Presentation," does that actually mean
> user interface?  But there's also the back-end network with its
> BEBE protocol, which tries to be conceptually invisible to the
> user.  Not sure it's in Green anyway.

In ISO when describing TCP/IP, they hang bridges btw middle layers,
indicating the logical link layer exchanging packets.  I think I can
represent the BE-BE interface the same way.

But no, Green doesn't implement the BE-BE interface at all.

> I guess what I was trying to do in the diagram
> http://www.tiac.net/~sw/2004/08/xanadu/ is get to a kind of
> observation tower in the middle: it's like the web, but at heart it's
> an index that allows multiple arrangements of stuff, and
> tracing the connections from arrangements to stuff back to arrangements,
> all in an efficient way.  From there you can go uphill into how you
> exploit that to make something better than the web, downhill into
> how the data structures work, and sideways into distributed and
> carved-apart implementations.

An interesting image, I'll have to ponder that.

> For the data structures, I would start with model T's, then say they
> aren't actually used in the obvious way because they don't go
> backwards, then go to 2D, then bring
> in how pooms and spanfilades let you show correspondences, and
> finally tie down the details of tumbler addresses,
> granfilades, berts and orgls and the fine alignment of parts.
> Of course, inside the code you're seeing tumblers running all
> over the place, so if you want someone to quickly touch code your
> order makes more sense.