 |
Technical Overview |
Though applications built using Udanax Green appear to be one program, they have two communicating parts: a frontend and a backend. The user interacts with the frontend. The data generated by the frontend are stored, edited, and interconnected in the backend.
Frontend
The Udanax Green hypertext system supports multiple media. Thus, the user interaction in the frontend might consist of recording movies or voice messages rather than simply editing text. The frontend also imposes semantics on the data stored in the backend. For example, it translates picture data to pictures, sound data to sounds, and text data to text. Different frontends which manipulate different kinds of data can all communicate with the same backend using the FeBe Protocol.
Backend
The backend does:
* interconnection (link) storage
* editing operations
* version management
* finding information
* access control
* multi-user access
The Udanax Green objects in the backend visible to the frontend are:
account - one for each user
document - the unit of storage
version - a document in a version history
link - the interconnection
bytes - a data element in a document
contents - data-bytes and links together
Documents are the units of storage in Udanax Green. They store both data-bytes and their interconnections. The data-bytes can represent any medium, from text to digital video. Each document has separate address spaces for the data-bytes and links (interconnections) within it. The first space contains the data; the second the links. The two spaces together make up the entire contents of a document.
.i.Links
Udanax Green links explicitly represent the interconnections between pieces of data. A link connects any set of Udanax Green objects (data-bytes, links, ranges of documents, etc.) to any other set of such objects. They can connect data within a single document, or across document boundaries. Each link has a completely general type field. Frontends can use type information when displaying, matching, or following links. This generality makes links ideal to represent the complex, irregular relations between data in unrelated formats.
Each link is installed in a document when created. This document is the home document for the link. The link can be copied to other documents, but its home remains the original birth place. The location of a link is independent of the things it connects, however. A link in one document can easily point from another document to yet a third document.
Link Matching
To support the general link facility, Udanax Green provides a very powerful operation for finding links that satisfy a set of constraints. Possible constraints include tests on each link's type, author, start location, end location, and home. (See the chapter "Links and Link Types".)
Editing and Links
Links that attach to the contents of a document must interact in a sensible way with editing operations on that document. The basic metaphor for that interaction is that links attach to the bytes themselves, rather than simply the location within the document. Thus, when the bytes in question get moved, copied, etc., the link stays attached to them. (See the chapter "Links and Link Types".) Maintaining link connections despite editing operations requires that the backend do the editing operations on the stored data.
Parallel and Sequential Versions
Two versions of a document are distinct documents related by edit operations. Udanax Green creates a new version of a document by making an exact virtual copy. Sequential versions appear if only one of the two versions are edited. Multiple releases of documentation demonstrates sequential versions. Parallel versions arise when the two documents are edited independently, such as when two authors customize a single software manual for different applications of the software.
Comparing Versions and Documents
To round out the version mechanism, the backend provides an operation for comparing two documents. The comparison operation determines the contents shared with another version of the same document or contents copied to or from another document. In both cases, the backend records the intentional sharing of contents. The comparison operation returns this information.
Links and Versions
The version creation operation creates a virtual copy of all the objects in a document. Links that attach to these content objects remain attached even when the objects exist in more than one document. Thus, links to the shared contents of two versions are visible from within both versions. This only happens to shared content objects, not to bytes and links inserted later.
Finding Udanax Green Objects
Link matching is the primary operation for finding objects stored in the Udanax Green backend. (See the chapter "Links and Link Types".) The system can also show implicit connections from data and links to all the documents containing them. Editing and version creation operations both establish these connections.
The backend operations for finding Udanax Green objects depend on the special Udanax Green data-structures -- the Enfilades. String searching operations, for example, gain nothing from the backend architecture, and so properly belong as part of the frontends which require such operations. (See "Fe vs. Be".)
Access Control
The backend manages contention between multiple frontends for individual documents by requiring each to edit their own version of the document. This automatic version creation allows frontends to transparently operate despite other frontends. Frontends can later resolve conflicts using the version comparison operation.
Multi-User
Multiple users can use separate frontends simultaneously, accessing a single backend through the FeBe Protocol over the network. Each user has a different account. The automatic version creation on contention and the version handling facilities combine to support multiple users interacting with the same set of documents.
