"Xanadu" and the Flaming-X logo are registered trademarks of Project Xanadu.
1 Visitor(s) on Site 98 Wiki Pages
How This Wiki Works
|Recent Changes Printable View Page History Edit Page|
Content Last Modified on December 27, 2006, at 09:11 PM CST
Glossary of Common Xanadu Terms
"Berts are the soul of a document and represent the discrete, persisting identity behind the changing representations of that identity. As changes are made, a document visits different states (represented by new Stamps), and whenever a particular state is blessed with a BertD? hopped from a predecessor StampD? we refer to the result as a new "editionD" of the original document.
When a document is replicated a new BertD? is created representing a new and separate identity; we refer to this as a "variation" on the original document, anticipating a distinct intent by providing a distinct identity and state/edition history capability (note that the term "variation" is somewhat presumptuous, but not overly so since it fits our reasonable expectation of actual changes representing a new intent). "
A blast can be triggered deliberately by a bomb.
Named after bread crumbs, the Crum River which runs through or near Swarthmore College, and, "Code, Recursive and Universal, for Meanders." Meanders being, essentially, spans of text within editions. Someone anonymous in Mark Miller's Ent class says it also means "chickens running under mud."
For POOM enfiladeD, see Permutation Of Order Matrix.
The new thing the ent does is that you can access it from the bottom or the top to get inverse mappings. (Only now that the two are symmetrical, they're renamed North and South.) That means that nodes can have multiple connections in both North and South directions. Look at EntTheory after reading EnfiladeTheory?.
The ent was originally conceived by Eric Drexler (as was at least one Udanax Green enfilade). I don't know whether he invented the Canopy. The ent is named after the "the walking trees with great memory in J.R.R. Tolkien's Lord of the Rings", according to Ted Nelson.
Objects migrate to and from the disk in groupings called "flocks". The flock is the minimum granularity at which objects are purged from core and restored from disk. A flock consists of exactly one shepherd and an arbitrary number of sheep (as long as the entire flock is guaranteed of fitting in a single snarf? Is this true? Michael? Dean? How can we be confident this condition is satisfied?). A "sheep" (what is the singular?) is simply a "COPY(X):" object which needn't be at all cognizant of the disk. The single shepherd in a flock is "representative" of the flock as a whole--the only inter-flock pointers are to shepherds.
This means that the only on-disk pointers to a sheep must be from objects within the same flock as this sheep. If a sheep is an EQObject? there is no problem, because a hash table that points to it must be within the same flock. Given that hash-indexed structures rehash when being read back in off disk, the flock will always be using valid hashes during its stay in core.
It appears to be a front-end codebase(?) for developers and was written in Smalltalk/X++. --JohnDougan
More info coming soon...
Before I proceed further, I should mention that because of an earlier observation by Robin Hansen, a new element has been added into the computational lexicon: "moose." A moose is an inadequately addressed design issue that is potentially very large and very nasty. It could be thought of as a metabug, as it is a problem that exists before code is even written, and could therefore produce bugs (or spoilage) if unresolved. The origin of this term comes from a design meeting where Robin accepted the task of logging issues that had been swept under the rug. At one point he made a comment to the effect that, "it looks like you've swept a whole moose under there." In the Xanadu design effort, this term has proved invaluable--the language, however, may never be the same. --JohnDougan
In udanax-green, an ORGLD is a 2-dimensional enfilade representing a permutation matrix, or POOM.
Does the Patriarch manage the Shepherds?
Copied from a forum message
A "sheep" (what is the singular?) is simply a "COPY(X):" object which needn't be at all cognizant of the disk.
The single shepherd in a flock of sheep is a "representative" of the flock as a whole -- the only inter-flock pointers are to shepherds. --JohnDougan
Snarfs are units of data exchange that grew out of typical disk data transfer rates compared to typical seek times. A snarf has a size that is optimized for the transfer to seek ratio of the mass storage device used-- roughly a track. By reading a track-sized chunk of data structure into main memory, one is likely to get a large amount that will be needed immediately, with virtual no additional cost for bringing in the unneeded parts. --JohnDougan
TapestryD? was designed to optimize the presentation of evolving collections of documents. It was designed to be a smooth scrollling system without the chunkiness present in systems like HyperCard??. --JohnDougan
A tumbler is like the number assigned in the dewey decimal system or in SCCS style revision numbers. An example tumbler would be: 18.104.22.168.22.214.171.124.67.0.8126.96.36.199.0.2234
A tumbler is an example of a transfinite number. The advantages of this as a numbering system for Xanadu addressing are:
1. There is always a tumbler between two different tumblers, so insertions never require renumbering.
2. A set of tumblers can be ordered.
3. The tumblers can be arranged to form a hierarchy, making it easy to specify all tumblers that start with a shorter tumbler. This is used in the Xanadu green system for queries like "all documents of this user". This is also useful for delegating assignment authority, like in the DNS.
4. Arithmetic can be done with tumblers. Specifically addition and subtraction, making it possible to specify ranges of tumblers.
In Xanadu green, the tumblers are in the form (with all components specified): 1.<node>.0.<user>.0.<document>.0.<content> where each <piece> is a tumbler fragment.
So the tumbler specifing the 3rd text byte of the document 10.3.5.6 for user 77.2334556.78.2 on the node 99.432 would look like 1.99.4188.8.131.5245184.108.40.206.10.3.4.6.0.1.3 . Shorter forms are allowed as are tumbler differences, so asking for all data starting from 1. with an extent of 1 will give you everything in the system. Asking for all data starting from 1.99.4220.127.116.114556.78.2 with an extent of 0.0.0.0.0.0.0.1 will give you all of the documents belonging to user 1.99.418.104.22.1684556.78.2.
The Unusually Reliable Disk Interface developed by Michael Mc Clary gives us a degree of incremental recovery from system failures that we have long been wanting. As with any heavily cached system, Xanadu runs the risk of having an inconsistent data structure on the disk after crashes and power failures. Buffering in most operating systems and high-end disk drives only aggravate this problem. The URDI allows a consistent, although not necessarily current disk data structure to be achievable after when restarting the system after some, but not all failure modes. Some the modes that we are not protected against are spiral writes and head crashes. The metaphorical model that Michael has used is Fibber Mc Gee's closet. The closet represents the main storage area on the disk where most reads take place, and a consistent data structure is more or less guaranteed during execution of user requests. Writes, however, go through a staging area on their way to the closet, where groups of snarfs are placed in temporal order. At the end of each group is a marker indicating that if all of the staging area up to that point has been put in the closet, the disk will be consistent. After a failure, this area will be processed before acknowledging any requests. While this will result in some delay at system restart, it is immensely faster than reevaluating the entire transaction log. --JohnDougan
A waldo is also the name for remote manipulation equipment of the type that copies the hand/arm motions of the user.
|Recent Changes Printable View Page History Edit Page|
|All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest (c) 2001-2007 Jeff Rush|