Whiteboard: Puzzles	last revised by 24.68.13.4 on Aug 17, 2005 3:37 am

This Wiki page is for the collection of rambling questions, which informed members can drop by to answer as time permits, and then the material will be integrated elsewhere on the site.

ACCESS CONTROL

• How was Xanadu originally intending to handle access controls? If we only control the visibility of links and not the text streams themselves, someone could exhaustively cycle thru tumblers and view private text. Right* the text streams need to be protected as well, this isn't implemented, but is reltively easy to add to the open document stuff.

• While Literary Machines discussed public/private document spaces, where in the protocol/architecture is the bit indicating to which group a particular document belongs? And what is the API to toggle that bit? nope not there yet* however see above.

• And since Xanadu is intended to prevent broken links by making it difficult to remove a published document, is there support in the current architecture to delete or blackhole a portion of the Istream, in order to administratively remove information but retain the integrity of the linkages? again no* However, it would be relatively simple to hack thatin. There is no reason that it should be part of the API, it's an adminstrative function. However, in some cases the thing blacked out should be a V thing rather than an I thing.

• Suppose you create a research paper in Xanadu and make it public. Everyone reads it and links to it. Now, you begin work on the next version and it takes you several weeks, during which you want Xanadu to maintain an historical trail of your work. You are a private individual and don't want your drafts visible publically but only selected versions.

  How do you keep people from reading your drafts? Sure you can avoid making any public links to your draft versions, but someone who has access to your version 1 copy can use front-end functions to follow your document forward in time, viewing your drafts.

CHRONOLOGICAL SEARCHING

• Literary Machines only mentions very briefly that the final system will support sieving documents based on their time of creation, but no hints are given at all of how. The current tumbler and link architecture doesn't seem to address this matter. My theory is use links and have a spanned link of type time automatically added over each range of new material, but this might not scale well.

VERSION BOUNDARIES

• It is unclear when a new version is created during a user session. Is a new version created for each keystroke/editing command? Is one created at the end of each user session? Or is one only created when explicitly asked for?

  And should the front-end perform auto-saves periodically, thereby creating spontaneous new versions? Answer* "It's a frontend function. Rather, one could do that. It would be wrong, but one could. A new version is created a) when asked for b) when one tries to open a document that is already open. Thus the frontend could but shoulden't create a new version for each keystroke, or each second for that matter. What do you mean autosave? The insertion in the backend saves it. Makeing a new version does nothing effective, how could it.

• When does a particular version of a document become frozen? When a new version is created or when explicitly locked? And is the lock undoable if there are no links into the document that would be broken? It certainly has to be frozen before inter-document links are permitted to it, or those links would be shifting about. No! what are you thinking* interdocument links to non frozen documents are prefectly ok. Freezing is mostly a convienence for distribution of documents to other nodes. For a frozen document they needn't check for modifications to the document.

• Or does the front-end store any non-frozen or auto-saved work-in-progress to a local disk, and then later upon command post those to the back-end? Note: the frontend could save stuff, but why* As soon as the frontend communicates to the backend, the stuff is saved. Autosave is a frontend concept, that I don't understand, what is it that is lying around that hasn't goten to the backend yet, and why?

HISTORICAL WORK

• Did the Xanadu team ever do any performance measurements on the Green code? I can't seem to find any test programs.

• Whole bunches of runs of various documents inserted and retrieved were run. We did a bunch of profiling on that. More info available (too much really) if anyone wants it.

• Was the Back-End <-> Back-End protocol ever defined? The way the Istream is handled, I can see how a Back-End can use the tumbler to know where to go get the bytes, but how does a Back-End in Dallas, say, know there a link was made in Chicago that points to a document in Dallas? For the case where I want to query all links, anywhere in the world, that reference a document in Dallas?

• Ha goccha The Be-Be protocol thouch not defined is quite straightforward. It has to communicate the bytes and the Poomfilade. The Be-Be doesn't know the location stuff, it is used for the communication of stuff that is there, either between server nodes, or to backup media.

  The protocol on where to find things is at a higher level. Ecentially, a map is built up of where things are moved to. The map needn't be complete, but can diminishing resloution with "distance". The necessity of such a mapping was the driving motivation for the naming system, though other kinds of naming could be used they don't seem to lend themselves to deminishing resolution so well.