[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Presentation on Xanalogical Data Structures
- To: Steve Witham <sw@xxxxxxxx>
- Subject: Re: Presentation on Xanalogical Data Structures
- From: Jeff Rush <jeff@xxxxxxxxxx>
- Date: Fri, 13 Aug 2004 01:43:44 -0500
- Cc: udanax@xxxxxxxxxx, xanadu@xxxxxxxxxx
- In-reply-to: <p06002003bd41439641cb@[10.0.1.102]>
- Organization: Tau Productions Inc.
- References: <1088593794.19829.81.camel@xxxxxxxxxxxxxxxxxxxx> <1091854291.4865.14.camel@xxxxxxxxxxxxxxxxxxxx> <p06002005bd3d69f7ba3f@[10.0.1.102]> <1092290997.10235.82.camel@xxxxxxxxxxxxxxxxxxxx> <p06002003bd41439641cb@[10.0.1.102]>
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.
-Jeff