Evaluation of the Hyper-G Server

Omer Casher and Henry S. Rzepa

Hyper-G was developed by the Institute for Information Processing and Computer Supported New Media (IICM) located at the Graz University of Technology, Austria. A Hyper-G test server was set up on the SGI Indy at Imperial College and has been running alongside the Netsite Commerce test server since October 22, 1995 without problems.

The special flavour of this server is exemplified during installation. Only one Perl script is downloaded from IICM. Running this script opens communication between the Indy and IICM's own Hyper-G Server. The IICM Server then places all the programs and scripts in their proper locations. When the local Server is ever updated, the IICM Server will update only those files for which newer versions exist. A local demon can periodically check the IICM Server for updates and automatically propogate the updates to the local server.

We are investigating the potential here using our Explorer EyeChem as a testbed. EyeChem is basically a suite of molecular visualisation modules. They are grouped with other Explorer modules to form EyeChem applications. The collection of some 30+ modules and example applications are publically available for SGI users.

As various EyeChem modules are updated and new modules and example applications are added to the suite, keeping the public archive current is very tedious. Moreover, the only means repeat visitors have of knowing which modules have been updated is to either browse the archive, which is time consuming, or to download everything, which wastes bandwidth. A mechnism to automatically archive the modules and pass only the updates on to users when requested would be both useful and directly applicable to clic.

Hyper-G runs only under Unix. It uses a "Client/Server Protocol" that differs from http in several ways:

  1. The TCP connection is not closed and re-opened between transactions, but stays open for the duration of a session.
  2. A client may choose to issue a number of commands in succession, and look at the results later. This is an advantage when the client accesses more than one journal entry.

There is also a Server/Server protocol to maintain information base consistency across server boundaries. Each server has a top-level directory called a Hyperroot which contains a list of all Hyper-G Servers. The Hyperroot is updated by a server-server communication, propagating new servers from one to the other. Additional protocols include a Client/Client protocol that allows Hyper-G clients to pass messages and events to each other using the server, and protocols for communication between the individual parts server.

A Hyper-G server is structured as a "collection hierarchy" which is similar, but not identical, to a directory tree. Hyper-G is not designed as a document preparation system, but as a document dissemination system at the lowest common denominator. It supports a wide range of users and user interfaces, starting with simple terminals. To benefit from Hyper-G's capabilities, files should be inserted into the collection hierarchy in Hyper-G Text Format (HTF) which is similar to HTML.

For now, translating the ISO 12083 dtd into the HTF dtd would be accomplished by applying a ``pre-renderer'' that maps the semantic elements to simple HTF elements. HTF i s now being superceded by HTML. In the future, it will eventually support arbitrary SGML DTDs. What this means, in theory at least, is that an entire SGML database can be stored in a Hyper-G server. Inserting SGML documents will be accomplised by any one of the Hyper-G existing clients including the high level Amadeus and Harmony.

Since Hyper-G servers can intercommunicate, the SGML database need only reside on one server, such as a dedicated PC running Linux. The other Hyper-G servers can then fetch documents from this server as needed, convert them to HTML or PDF, and send them off to the HTML client that requested them.

Clearly Hyper-G is a viability server for Chemical Communication. However, it has not yet achieved widespread use and many of the existing Hyper-G servers are test servers such as ours. The "next generation" HTTP-NG server, which promise to offer much of Hyper-G's functionality is a viable alternative. There is some indication that Hyper-G will fully migrate over to WWW.

The status of the Journals Storage Database at the RSC will need to be established. Among other issues we need to establish:

  1. a document delivery mechanism where the Challenge S server will retrieve the SGML version of a requested document from the Database and translate it into HTML as it is sent to the client.
  2. what portion of it, if any, can be duplicated and placed at the three sites.

We are in contact with the Hyper-G Development team. The feasability of Hyper-G depends largely on the amount collaboration we can achieve with them.