From: Kenneth M. Anderson (kanderso_at_ics.uci.edu)
Date: Tue 10 Jun 1997 - 17:24:33 CDT
After spending the last few months fighting the dissertation beast and finally putting it to rest in the University Archives last Monday, (and taking about a week off to celebrate) I'm ready to focus my attention back on the OHP, Chimera, and the JoDI version of my workshop paper. I'm going to include in this message a summary of my plans for the JoDI paper, and a few brief responses to some of the threads that have gone through the list recently.
I would like feedback from the list about things you would like to see in the paper, and also if you feel that you are addressing an important OHP issue in your JoDI paper, please let know so that I can include links to the relevant arguments.
2. Opaque LocSpecs
Peter J. Nuernberg wrote (this quote is a great simplification):
>I propose that the OHP treat locspecs as opaque byte blocks.
I responded (paraphrase):
>Sounds great to me! We should modify the definition of the locspecs to
>include a length field (in bytes) of the locspec and then those not interested
>in the exact format of the locspec can safely ignore them.
Randy Trigg responded to Peter's proposal:
>I like the simplicity of your proposal, especially given how many complex
>issues are wrapped up in locSpecs ranging from search specs to anchor
>On the other hand, I'm concerned that your proposal will preclude
>interoperability between different HSs. At the very least we would need to
>name different locSpec templates (or "styles") and record the template name
>with the byte blocks on the server. Then those names would need to be
>understood by potential clients.
Peter responded to Randy:
>I think this might be an issue of where this knowledge should reside,
>or more correctly, I guess, at what level. I think that your comment
>about styles (just like presentation spec styles) is exactly on
>target. It makes sense for us as a community _apart from the protocol
>discussion_ to agree to some minimal set of locspec formats and rules
>for extending that set. But, in terms of the protocol, I think it
>makes sense to just say that we are shipping something that we don't
>need to or want to understand.
Now I respond to this whole issue:
I must definitely cast my vote with Peter on this issue. From the Chimera point of view, locspecs are completely client-dependent. I agree that there should be some standard format for the locspecs and I think there is some excellent work in this area as Randy mentioned in his post. However, we should not require the OHS to understand the contents of a locspec, and the format of the locspec should be setup so that it can be parsed rapidly by those OHSs which treat locspecs as opaque. I.E. I would hate to have to implement a locspec parser when I have no intention of interpreting them! Rather, I just want to store the bits and pass them back to the appropriate clients when needed.
3. "Active" Documents
Sigi Reich wrote in response to Peter's comments on GetAnchorTable:
>In working with the LocSpecs of OHP I had the same problem in that I also
>thought a document ID (= "node identifier") would be useful (and needed).
>So I added one to the proposal for 'more' HyTime conforming LocSpecs.
>Re-reading the original draft of OHP I understand that the "GetAnchorTable"
>message is preceded by a "HeresDocument" or "LaunchDocument",
>respectively. The message then applies to the 'current', i.e. active, document
>(assuming that there is just one active document per viewer /
>application). This would also mean that the linkservice is stateful in that
>it remembers its sessions and the according documents.
>Anyway, it might make sense to get the anchor table for an other document; or
>there might be more than one 'active' document per viewer.
I failed to notice this aspect of the OHP in my workshop paper. If I had noticed it, I would have definitely brought it up! The OHP should not assume that a client has only one document open at a time. So I agree with Peter and Sigi that we need to add an identifier to provide context for operations that store and retrieve hypermedia information. This would support the scenario where a client may display a compound document (thus having only one document open but...) that requires different anchor tables for each portion of the document. I believe Randy and Kaj brought this issue up at the workshop when they touched on the issue of composites. For the JoDI paper, I will examine the OHP spec for any other instances of this type.
4. Channel Information
Hugh Davis wrote:
>In OHP we originally inserted the idea of a "Channel". This was an opaque
>identifier inserted by the linkservice which was unique for that
>linkservice, and which enabled the linkservice and the client to communicate
>assynchonously. i.e. one could send a message, and the other could reply at
>a later time, rather than hold the socket open until it is ready to reply.
>In otherwords, this channel held the required information to route the
I'm not going to include the rest of the thread which sprung from this comment since I think this paragraph gets to the crux of the matter. We need to decide if the OHP is going to be a stateful protocol or a stateless protocol. I think of the two different types in the following manner. A stateful protocol has a client establish a connection to the server, pass over some initialization information, and then hold the connection (e.g. socket) open between the two for all subsequent communication. As a result, the hostname and the port of the server are only needed to establish the connection, and the initialization information is sent only once. A stateless protocol requires that the client do each of these steps for each message sent to the server. It also requires that the client have the infrastructure within to be a server such that it can be sent asynchronous messages. In the former, there still has to be some code which manages asynchrounous messages from the server but these messages can be sent across the open socket connection established by the client.
I have always thought of the OHP as being a stateful protocol, whereas Hugh's paragraph above indicates that he has been thinking of it as a stateless protocol. I have always implemented Chimera's protocols as stateful protocols and thus I have sort of a bias towards this approach. I guess its major benefit over stateless protocols is that if you have a situation where you have lots of operations and requests and messages flowing between a client and a server, the stateful protocol eliminates the overhead associated with creating a socket and passing initialization data for each message sent.
5. The scope of the OHP
Jim Whitehead asks:
>How broad should the OHP be?
As just a reminder of what I said in my workshop paper, I believe that the initial version of the OHP should cover the creation and manipulation of links and anchors, and the ability to initiate and receive link traversals.
6. Who will use it?
Jim Whitehead also asks:
>So, who do you see using OHP clients?
I think initially the use of the OHP will be confined to the open hypermedia systems community. We are going to have to go through a few rounds of designing, implementing, evaluating and extending the protocol to get it to the point where we can broaden the audience and enter the IETF standards process. I can be persuaded to start that process earlier, this is just my current take on the situation.
Sorry for the long response, but I'm playing catch-up here. Now that I'm working on the JoDI paper full-time, I should be a lot more responsive to the issues discussed on this list!
P.S. Kasper, I would love to get a copy of the photo you took of me at Stonehenge! Let me know if this is possible...
Kenneth M. Anderson | Read books by Michael Moorcock Graduate Student | <mailto:kanderso_at_ics.uci.edu> University of California, Irvine | <http://www.ics.uci.edu/pub/kanderso/> --------------------------------------------------------------------------
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:47 CDT