From: Peter Nuernberg (pnuern_at_daimi.aau.dk)
Date: Wed 10 Jun 1998 - 10:18:57 CDT
Hi OHS'ers-
This is a rather lengthy mail describing some of the details of the first OHSWG standards implementations that will be demo'ed at HT 98. This message is divided into several sections. Section 1 gives some background. Section 2 describes some of the progress we've made on the standardization front. Section 3 describes the sample implementations that will be demo'ed at HT 98. Section 4 describes what we can demonstrate. Section 5 discusses some open issues. Section 6 lists some resources.
Although we are still to date without a formally adopted referenece architecture, we seem to have come to an agreement that the "middleware" layer of hypertext systems/environments consists (conceptually) of several components. Each component implements some interface. Our standardization effort addresses in part the definitions of these interfaces. It also addresses how (physically) to deliver these services to clients, as well as issues that cross interface boundaries (such as naming).
The entire standardization effort has gone under the name "OHP".
Individual interface standards have gone under the names "OHP-x", where
"x" is some abbreviation. The only interface standard to have received
any substantial attention to date is OHP-Nav, which is the proposed
standard for the interface to components that serves "traditional"
navigational (link/node) structure. Initial efforts are underway on the
OHP-Space (spatial hypertext) and OHP-Work (hypertext-based workflow)
interfaces. There have been discussions about the possibilities of
OHP-Lit (hypertext-based literature), OHP-Tax (taxonomic hypertext), and
other interfaces.
2. Progress
Progress on many fronts has been frankly slow or non-existent. However, enough has come together to allow initial implementations of OHP-Nav compliant clients and servers. Some specifics of the relevant work is below:
OHP-Nav service definition-
initially agreed to at OHS 3.5 and confirmed by the
"on-the-wire" (OTW) subgroup, we are using IDL to define the interface
definition. The OHP-Nav interface definition _as implemented_ by
numerous groups (see below) will be made available shortly. It differs
in small details to the last publicly circulated draft.
OTW component framework choice-
OTW subgroup has decided on Java Beans / RMI as a suitable component framework for implementing OHSWG standard compliant servers and clients. At the time of this writing, no fully compliant OHP-Nav beans have been written.
OTW non-framework definitions-
OTW subgroup was also charged with defining a way to send messages over TCP connections between entities that could not or did not choose to use RMI to send requests and notifications to one another. The subgroup has not officially come to any decisions regarding this. However, since all the current implementations of OHP-Nav compliant software use TCP-based communication, there has been a de facto standardization of the non-framework communication format. We have chosen to define messages as (essentially) XML documents and message suites with XML DTD's. The XML DTD for TCP based OHP-Nav communication will be made available shortly. With minor work, the bytes streams generated by implementations of OHP-Nav servers and clients can be verified using one of many freely available XML validating parsers.
3. Implementations
There are currently three sets of OHP-Nav compliant software that have been tested with one another. These are:
Construct-
is a joint codebase successor to the HOSS and HyperDisco systems. There is currently a multi-user, multi-session OHP-Nav compliant server named NavMan and a wrapper process that wraps an integrated GNU Emacs.
DHM-
DHM Hypervise client ("client side foo" in current OHSWG
architecture terminology) has been integrated to speak OHP-Nav.
Currently, tests have been carried out with an integrated MS Internet
Explorer speaking to the CSF. Other clients may be tested with the
OHP-Nav compliant CSF before the HT 98 demo.
Southampton-
Southampton demo software consists of a compliant server and a compliant CSF. Tests have been carried out with a custom-written JPEG viewer that speaks to the Southampton CSF. Other clients may be tested with the Southampton CSF before the HT 98 demo.
Ken Anderson is at work to convert some of the Chimera software to the current OHP-Nav standard. This may be completed by the time of the HT 98 demo.
Some groups hope to make available substantial portions of the above implementations at the demo.
4. What we can demonstrate
On the interoperability front, we have tested the following to date:
Construct client / Southampton server
DHM client / Construct server
Southampton client / Construct server
We expect that the missing combination (DHM client / Southampton server) will be tested before the demo. There are no plans for an OHP-Nav compliant DHM server for the demo.
In addition to exercising the "basic" functionality in the
specification, we have tested collaborative authoring sessions across
different machines and clients from different groups, as well as
"collaborative browsing", or the possibility for multiple clients to
receive the same traversal result (endpoint display notification),
although currently, the latter requires the Construct NavMan, while the
former requires both the NavMan and that collaboratively authored links
(not their endpoints) be created by the Emacs wrapper. We expect that
the Southampton and DHM CSF's will be modified to allow the creation of
collaboratively authored links by the time of the demo.
5. Open issues
The demo implementation effort has pointed out a number of areas and issues not addressed well or at all by the current OHP effort. Some of these issues are listed below:
General issues
Currently, there is no clear picture of what a CSF is exactly or whether or not it s required. This must be resolved for our standards to avoid underdefinition.
Naming-
has been no progress on object or entity naming. The two current compliant server implementations use disjoint namespaces. Although this works, we may want to examine benefits of unified namespaces.
Location-
location is currently done by convention, which themselves vary between the server implementations. This must be addressed by the group.
Connection managment-
servers expect that clients maintain a connection across their lifetimes. Provisions should be made for clients that wish to use connections that persist only for the lifetime of requests or notifications.
State-
is no defined state for compliant servers or clients, making collaborative link authoring difficult. (It is currently accomplished by keeping state in the Emacs wrapper, and hopefully, by the time of the demo, in the DHM and Southampton CSF's.) This issue must be addressed.
OHP-Nav issues
--------------
OHP-Nav service set weight v. power-
The OHP-Nav service set consists of nearly 40 services, many of
which go completely unused in all implementations (making it somewhat
heavyweight). In comparison, many proprietary client protocols consist
of a much smaller number of messages, thus pointing to the possibility
of a lighter, smaller protocol, even if we keep the current data model.
Also, many "common" operations require several OHP services, suggesting
that the current service set consists of insufficiently powerful
operations.
OHP-Nav semantics-
document clearly describes the intended semantics of the OHP-Nav services.
Miscellaneous issues
No session semantics are defined in OHP.
Concurrency control-
provisions are made for locking.
Access control-
provisions are made for permissions granting or checking.
Version control-
provisions are made for versioning.
6. Resources
The OHSWG WWW site (http://www.csdl.tamu.edu/ohs/) contains more
background material as well as archives of the traffic on this list
and lists for the various subgroups of the Working Group. There is an
"HT 98 demo site" (http://www.csdl.tamu.edu/ohs/ht98demo/) that
contains some discussions specific to the demo. Sigi Reich has
assembled much information relevant to the demo and the OHSWG's work
(http://www.ecs.soton.ac.uk/~sr/...). You should be able to find
up-to-date XML and IDL specifications on Sigi's page. They will be
moved to the official sites shortly.
The specifications referred to above will be posted on the OHSWG site shortly. A version of the Construct software will be made available at the HOSS and HyperDisco WWW sites (http://www.csdl.tamu.edu/hoss/ and http://www.aue.auc.dk/~kock/projects/HyperDisco/) by the time of the demo.
A Construct NavMan available for public use is kept running on
"sundew.daimi.aau.dk:9000". This will (hopefully :-) remain running
until the time of the HT 98 demo, except for periodic updates. The
source for the Construct NavMan, a test client, the Emacs wrapper, and
the Emacs elisp integration library are available upon request (mail
to "pnuern_at_daimi.aau.dk" or "ukwiil_at_aue.auc.dk").
The Southampton Navigational Link Server is also available for public use at "lewey.ecs.soton.ac.uk:7777". Software is available upon request from "dem97r_at_ecs.soton.ac.uk"; these include the Soton CSF and associated tools, ImageViewer and the java component of the Link Server (N.B. it requires a jdbc compliant database, it has been prototyped with MS Access).
-Pete
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:34:19 CDT