Introduction
This memo addresses the issue of how to implement phase zero of Yggdrasil. In this plan, we attempt to get a minimum function server usable at an early date.
In particular, we are using Camelot and Mach. We defer many of the more interesting aspects of the system, and try to get early users. We provide a basic hypertext system with few of the frills. This system should be useful to NoteCards.
Features needed in Phase 0
Below are the features of the system as taken from the overview memo. In strikeout are the features that are to be omitted in phase 0.
f large number of documents
but, no archival storage in Phase 0
f documents can be large
f documents can be small
but, will be allocated to whole pages
f only basic hypertext data model
f documents ``types'' understood by the system include text, bitmaps, digitized audio, digitized video (?), graphics, ...
f documents ``types'' are extensible
f documents can be connected via links (hypertext)
there are no references and there is only historic and foreign links (no version links)
f documents can be named via a ``hierarchical'' name system
cycles are not allowed
f documents can have attributes and keywords
f documents are grouped into contexts called containers
cycles are not allowed in the container DAG
containment and children are identical
f keyword and other indices maintained per container
f support for versions and alternatives
f data compression and decompression
f support for archival storage
f alerters (send a message when a system event occurs)
f query language and query optimizer
f page level access within a document
f transactions
f robust
f good performance
f fast recovery
f good availability
f access control
f hooks for multi-server and foreign server support
Overall Implementation Plan
The goal of Phase 0 is to get up a running server with a restricted interface, OK performance, OK recovery time, and modest availability. Phase 0 of Yggdrasil will sacrifice many of the interesting systems features of the project. However, the server would support the basic hypertext, naming, and indexing that are the key features of the data model. When the server runs in this mode, then it is possible to put up a server for a few clients. By putting up a server early, we hope to be able to measure its use, obtain client feedback, and build a history of success in the project. In any case, this approach allows us to scaffold up the higher levels of the system on available pieces of software.
The essential idea is to layer over Camelot. This will provide the transactions, logging, locking, recovery, and recoverable storage. We will port the Cedar File Package as the manager of recoverable storage (e. g., files, allocation, and deallocation). Code must be written and extended to simple navigational data model to use Camelot/Mach and the Cedar File Package.
Advantages and Disadvantages of this Approach Verses Previous Approach
Advantages
f early clients/client feedback
f apparent progress
f lots of shared code with final system
f implications for System 33 (indexing and storage)
f flexible about next stage (archival storage, better file layer, more of the data model, ...)
Disadvantages
f modest performance
f only basic hypertext data model
f fragmentation
f backup, crash recovery, and other "systems" issues only partly satisfied