Abora Features

The Abora hypertext system is intended to be composed of a server component, client API and a variety of client applications demonstrating the capabilities of the server. The server provides a sophisticated and general data management system. Some examples of its use could be as the core of a dynamic web-site, or as a document server for a company network, or even as the repository for a lifetime of personal notes, references and writings.

The following gives a brief summary of some of the tasks and uses that Abora will be able to help with:

• Heavy re-working of documents - flexible version support, visualisation of changes and inclusion of shared content
• Peer review of documents - categorised discussions on specific sections of content with filtering based on user and open associated tag information.
• Informal working groups - notification of document changes and new links enables spontaneous groups to form around specific documents as needed.
• Richly related documents - sophisticated linking and sharing of content between documents and versions enables a literature of works to be written and used.
• Distributed deployments - Multiple servers allows documents to be replicated for performance, reliability and easier access.
• Secure and controlled document access - user and groups enable flexible access to documents and integrated cryptography improves confidence of authorship and original contents.
• Long lived documents - document identity, sponsorship and distributed garbage collection keeps documents in the system as long as required, and can continue to be found and accurately referenced even after day-to-day modification.
• Beyond text support - all the above capabilities can apply to images, sound, movies and other arbitrary types of content.

Xanalogical Features

The core Abora features are inspired by Xanadu and derive from the capabilities of the underlying Ent data structure as present in Udanax-Gold.

• Transclusions or virtual-copies can be seen as a form of quoting except the quote is still connected back to the original text so it is always possible to find the original author of any character of text, and all other documents that share the same content. This helps against the problems of quoting out-of-context, and taking benefit from some-one elses work without proper acknowledgement.
• Implemented on top of this is support for fine-grained links that are typed and can be navigated in both directions. Links can be stored separate from the content itself to enable anyone to annotate any other document that they can view. In combination with typed links this enables low-overhead commenting of original text and structured responses such as refutations, agreements, acknowledgements. Links can also be filtered by users to focus on comments from respected or specific viewpoints. This will be a critical feature once hundreds or thousands of links have been attached to a document.
• Coordinate space mechanism allows content elements to be mapped over more sophisticated spaces than that of text or uncompressed audio. One possibility is the two dimensions of an uncompressed image. This enables transclusions and links to work across these numerous spaces, for example just the eye of an image of a face could be transcluded into a separate document, and a destination of a link could be to a few seconds of a sound sample.
• Sensors or detectors can be attached to objects to learn when certain actions occur. Some examples includes detecting when a new link is added to an interesting document, or when a new edition of a document is made. This can enable the spontaneous grouping of interested parties around a central document that acts as focus for the work.
• These features are all tied into a version system that ensures links stay connected to their original content and transcluded content stays available. Modifications to documents are stored at the level of changes initiated by the user, so between editions changes can be copying and moving in addition to the more primitive deletes and inserts that systems such as CVS would break user level changes down to.
• A significant force that shaped the Udanax-Gold design was the need for an implementation that could expand up to a distributed system comparable to todays World-Wide-Web. There is an interesting mix of mutable and immutable state that enables replication of data, together with idea of sponsors of documents and a distributed garbage collection system to ensure that documents are only removed from the system once they aren't referenced anymore or no-one is prepared to provide sufficient space for them.

Downsides

The features list summarises a series of very interesting differences against the standard WWW or even the innumerable custom web-site implementations. Given all this good news, what should one be concerned about?

• Complexity of the implementation is significantly higher than was found during the birth of the WWW. This has implications both to the time it will take to write a production-grade version of the server, and to the complexity and level of knowledge required by programmers that are interested in writing or extending clients. Where as any programmer could code up HTTP clients and servers on a whim, just writing a compatible Abora client will be a significant undertaking. Once the project has stabalized, producing well documented versions of the API with ample examples will be an important force on the greater success of the project.
• Server reliance is a constraint on the use of clients. A client needs to be in relatively frequent communication with a server, both to find content, but also during modification of content as the server essentially acts as a repository and needs to be informed precisely of higher level actions such as copying text between two locations. Contrast this to the use of CVS and a text editor; a CVS client is used to download a text document from the CVS repository, but then any text editor can make as many changes as it likes before eventually committing the new revision of the document back to the CVS server. It is only at this point that the server attempts to calculate the users changes, which will be encoded up as primitive actions such as inserts and deletes. This frequent communication with the server for Abora clients can be mitigated by running a server on each machine. The other effect though is that clients have to understand the Abora protocol, whereas the text editor knows nothing of CVS, as far as it is concerned it is just opening and saving text documents from the local filing system, and is oblivious to the CVS client which moves files to and from the external CVS server. An Abora client does have to know about Abora, and even with efforts to ease this communication with well documented APIs it will be a significant challenge to the quantity of clients created and extended to support the Abora server.
• Performance was a driving factor in the earlier development of Xanadu solutions, especially given the dreams of a world spanning system of interconnected servers. These efforts should enable the performance of the system to grow within a sustainable rate as data and servers are added. Other than question marks over sufficient analysis of the entire system to confirm these hopes, there might be the more pressing concern of performance in the small rather than the large. There are significant basic costs for operations and storage to implement the sophisticated linking, versioning and other capabilities. It is unknown quite how large this constant overhead is at this stage.