Re: Implementations of the OHP protocol?

From: Peter J. Nuernberg (pnuern)
Date: Mon 02 Jun 1997 - 13:07:17 CDT


> In our research group
> (http://www.cs.kuleuven.ac.be/~erikd/MANUAL/hgb.html), we will start
> experimenting with the OHP protocol. Basically, we want to gain some
> experience and investigate how this protocol could interoperate with our
> Hypermedia Object Management Environment (HOME). We are specifically
> interested in the client & server-shim and the communication between
> those.
>
> I was wondering if there already exist (prototype) implementations of
> the protocol and, if there are, if it would be possible to exchange code
> and/or experience?
>
> All comments and feedback are most appreciated!

We at the HRL at Texas A&M have been playing around with an OHP implementation. Here is some background:

In HOSS, the architecture specifies an open set of "link server" peers (called Sprocs). This means that we are not using the shim architecture to implement an OHP complient link server. Instead, we've just built a new Sproc that speaks this protocol. Although this is a new Sproc, it is modeled closely after our existing navigational hypertext link server, the Link Services Manager (LSM).

We have a certain amount of effort invested in development tools. One of these tools is called the Protocol Definition Compiler (PDC). The PDC acts much like an IDL compiler in CORBA environments. It takes as input a high-level protocol (service interface) specification and produces as output libraries for the clients and servers that take care of packing (marhsalling) parameters, sending requests, and optionally blocking on server replies for clients. The PDC does not generate libraries with functions that produce ASCII streams to TCP sockets. Instead, it uses the IPC infrastructure we've had here for some time. Messages in this scheme have a standard header (sender machine, sender pid, etc.) and a set of message-specific fields or parameters. The PDC both fills the generic header and packs the parameters into the specific fields and then sends the message to a port. From the PDC persepctive, the port implementation (TCP sockets, X window properties, shared memory) is transparent. The block sent to the port is binary, not necessarily printable ASCII. So, our current implementation doesn't meet the spec in this regard. The plan to remedy this is to add another module to the PDC to generate optionally libraries with functions that send and receive ASCII streams.

Here are some details:

  1. Context operations: Our LSM has context operations that open and close sets of links. We implemented these with the RequestService message. Certain other structural computations (e.g., check to see if all the endpoints of this set of links exist) using also use this message. This points out what I think is a big problem with the current spec. Since no semantics are assigned to operations (they are all just "provide service <x>") the interface has no way of providing operation specific calls for common operations. This is, however, a known point of contention in the group and will likely be debated again at the next OHS WG meeting.
  2. GetAnchorTable: I'm not really sure if I understand how anchor _(fwd link)_ tables are supposed to work. I added a "node identifier" (or document name) field to the GetAnchorTable message, since it seems strange to me that there is not one there. Perhaps I can use this opportunity to ask others what they think about this. Does this addition seem wrong to people? If this parameter is not there, which anchor table does the client retrieve with this call? I'd hope not "all anchors", since that seems to be nonscalable in the extreme.

Our current implementation is a bit messy, so I'd like to clean it up before I release it. We have two clients. One reads files from the files system and writes them to the backend. It also builds structures between these documents. The other is a cgi that contacts the Sproc for documents and structure and displays them as web pages. I'll try to post the demo of the CGI program sometime next week. In any event, once I post the source (late June), it'll be available for download. You need to install the whole HOSS backend, though, which ultimately requires Illustra 3.2.

I hope this helps.

-Pete

This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:33:57 CDT