| A Vision for Open Hypermedia Systems | Nürnberg and Leggett |
Since IR and composition structure management has been abstracted into other Sprocs, this navigation specification is less powerful than the current proposal. For example, it is not possible to model Microcosm generic links with this interface. The advantages of this finer-grained approach to service definitions over the current "union of functionality" approach are discussed above. This Sproc is designed to handle the task of navigation between explicit static links.
In general, one change that has been made to nearly all services is that they now concern multiple objects (e.g., the open document service can specify multiple documents). IPC is a very expensive part of any distributed operation, so messages should be combined and sent together whenever it is possible and natural to do so.
Many services can be requested by either the client or the server. When this is true, the message is listed only once, and the different semantics (if any) of the different directions are explained. This is in contrast to the current proposal, in which if there is one conceptual operation that either the client or server may request, two messages are defined.
Targets. There are four classes of entities in this protocol. The "all" class includes messages anyone can send and/or receive. The "server" class is the Sproc. The "browser" class is a client that only browses structures. The "author" class is a client that may modify structures.
TARGET all TARGET server TARGET browser TARGET author
Types. With respect to anchor identifiers, link identifiers, node identifiers, location specifiers, and presentation specifiers, the protocol will treat all of these as opaque byte block identifiers. The type id_t is predefined, and will be used throughout for all identifier types.
Scripts can be defined in various ways, but we propose handling them as NULL-terminated ASCII strings.
TYPE script_t ALIAS FOR NTstring;
We follow the current proposal's definition of an anchor as a binding between a locspec and a document (component) id. We also add attributes for a presentation specification, an (optional) direction, and a boolean indicating whether or not the anchor belongs to a link. Also, some systems (e.g., Chimera and the HOSS LSM) make anchors relative to not only a component and persistent selection, but also an application. Some systems "imply" an application in an anchor through the document type. Provisions for both methods must be made.
TYPE anc_t STRUCTURE ( doc_id : id_t; locspec : id_t; direction : NTstring; pspec : id_t; in_link : boolean; app_id : id_t; doc_type : NTstring; );
Document services. A Sproc can request a client to open and display a document. This message is known as "LaunchDocument" in the current proposal. Our "LaunchDocument" message makes the following changes. Firstly, the document may be identified by an identifier - some global (possibly non-ASCII) "name". Secondly, the data callback tag is removed. This is conceptually a client/storage engine interaction, even if in practice in some cases, the Sproc may be acting as a Storage Engine as well. Thirdly, since some systems do not launch applications to display destinations based on document type, an application identifier has been added. Finally, we change the name to "OpenDocuments" to imply some relationship to the next message.
Also, there is the notion of a client having independently loaded a document (i.e., not having been requested through an "OpenDocuments" message) and wishing to register this fact with the Sproc. This is analogous to the "CreateNode" in the current proposal. If the browser initiates this sequence, it receives a return code in reply.
SEQUENCE OpenDocuments server, browser
MESSAGE OpenDocuments server->browser, browser->server
{
num_docs : cardinal
doc_ids : id_1d[num_docs];
read_onlys : boolean_1d[num_docs];
doc_nicknames : NTstring_1d[num_docs];
app_ids : id_1d[num_docs];
doc_types : NTstring_1d[num_docs];
};
MESSAGE OpenDocumentsRespond server->browser
{
rc : rc_t;
};
The Sproc can request that a client close a document. This is analogous to the current "CloseNode". The current form of this message includes a flag that optionally indicates to the client that it should flush its copy of the anchor table for this document. However, it seems that there is no other facility for asking the client to flush its anchor table cache. This functionality should be effected in another message.
Also, a client should also be able to unregister a document. This is analogs to the "Closing" message in the current protocol. If the browser initiates this sequence, it receives a return code in reply.
SEQUENCE CloseDocuments server, browser
MESSAGE CloseDocuments server->browser, browser->server
{
num_docs : cardinal
doc_ids : id_1d[num_docs];
};
MESSAGE CloseDocumentsRespond server->browser
{
rc : rc_t;
};
Display services. A Sproc must be able to request a client to display an anchor. (That is, the client should make the anchor visible on the screen since it is the destination of a newly followed link.) This message is analogous to the current protocol's "DisplayAnchor".
SEQUENCE DisplayAnchors server
MESSAGE DisplayAnchors server->browser
{
num_ancs : cardinal
anc_ids : id_1d[num_ancs];
};
Anchor services. Sprocs may need to inform clients that anchors have been either created, deleted, or modified in documents managed by the client. Likewise, the client may wish to create, delete, or modify anchors. Basically, these services are implemented with the "RequestService" message of the current protocol. The current protocol's message "UpdateAnchors" is related to the "ModifyAnchors" below. If the author initiates these sequences, the server returns a return code and the anchors (and/or their identifiers) that were successfully created, deleted, or modified. If the author cannot allocate anchor identifiers, this parameter should be left empty. The server will supply anchor identifiers in this case. Either the server or author may request a fresh list of the anchors handled by the other.
SEQUENCE CreateAnchors server, author
MESSAGE CreateAnchors server->author, author->server
{
num_ancs : cardinal;
anc_ids : id_1d[num_ancs];
ancs : anc_1d[num_ancs];
};
MESSAGE CreateAnchorsRespond server->author
{
num_ancs : cardinal;
anc_ids : id_1d[num_ancs];
ancs : anc_1d[num_ancs];
rc : rc_t;
};
SEQUENCE DeleteAnchors server, author
MESSAGE DeleteAnchors server->author, author->server
{
num_ancs : cardinal;
anc_ids : id_1d[num_ancs];
};
MESSAGE DeleteAnchorsRespond server->author
{
num_ancs : cardinal;
anc_ids : id_1d[num_ancs];
rc : rc_t;
};
SEQUENCE ModifyAnchors server, author
MESSAGE ModifyAnchors server->author, author->server
{
num_ancs : cardinal;
anc_ids : id_1d[num_ancs];
ancs : anc_1d[num_ancs];
};
MESSAGE ModifyAnchorsRespond server->author
{
num_ancs : cardinal;
anc_ids : id_1d[num_ancs];
ancs : anc_1d[num_ancs];
rc : rc_t;
};
SEQUENCE GetAnchors server, author
MESSAGE GetAnchors server->author, author->server
{
};
MESSAGE GetAnchorsRespond server->author, author->server
{
num_ancs : cardinal;
anc_ids : id_1d[num_ancs];
ancs : anc_1d[num_ancs];
rc : rc_t;
};
Link services. Sprocs may need to inform clients that links have been either created, deleted, or modified in documents managed by the client. Likewise, the client may wish to follow, create, delete, or modify links. For the following operation, there needs to be an alternate form that indicates to the server that all destinations should be returned directly to the requesting client, regardless of how the destinations would normally be displayed. This is to allow automatic indexers to index an OHSWG structure space. These services are implemented with the "RequestService" message of the current protocol. If the author initiates these sequences, the server returns a return code. Either the server or author may request a fresh list of the links handled by the other.
SEQUENCE FollowLinks browser
MESSAGE FollowLinks browser->server
{
num_srcs : cardinal
src_ids : id_1d[num_ancs];
};
MESSAGE FollowLinksRespond server->browser
{
rc : rc_t;
};
SEQUENCE GetDests browser
MESSAGE GetDests browser->server
{
num_srcs : cardinal
src_ids : id_1d[num_ancs];
};
MESSAGE GetDestsRespond server->browser
{
num_dests : cardinal;
dest_ids : id_1d[num_dests];
dests : anc_1d[num_dests];
rc : rc_t;
};
SEQUENCE CreateLinks server, author
MESSAGE CreateLinks server->author, author->server
{
num_lnks : cardinal;
num_to_ancs : cardinal[num_lnks];
to_ancs : id_1d[num_lnks][num_to_ancs()];
num_from_ancs : cardinal[num_lnks];
from_ancs : id_1d[num_lnks][num_to_ancs()];
};
MESSAGE CreateLinksRespond server->author
{
rc : rc_t;
};
SEQUENCE DeleteLinks server, author
MESSAGE DeleteLinks server->author, author->server
{
num_lnks : cardinal;
num_to_ancs : cardinal[num_lnks];
to_ancs : id_1d[num_lnks][num_to_ancs()];
num_from_ancs : cardinal[num_lnks];
from_ancs : id_1d[num_lnks][num_to_ancs()];
};
MESSAGE DeleteLinksRespond server->author
{
rc : rc_t;
};
SEQUENCE AddAnchorsToLinks server, author
MESSAGE AddAnchorsToLinks server->author, author->server
{
num_lnks : cardinal;
num_to_ancs : cardinal[num_lnks];
to_ancs : id_1d[num_lnks][num_to_ancs()];
num_from_ancs : cardinal[num_lnks];
from_ancs : id_1d[num_lnks][num_to_ancs()];
};
MESSAGE AddAnchorsToLinksRespond server->author
{
rc : rc_t;
};
SEQUENCE RemoveAnchorsFromLinks server, author
MESSAGE RemoveAnchorsFromLinks server->author, author->server
{
num_lnks : cardinal;
num_to_ancs : cardinal[num_lnks];
to_ancs : id_1d[num_lnks][num_to_ancs()];
num_from_ancs : cardinal[num_lnks];
from_ancs : id_1d[num_lnks][num_to_ancs()];
};
MESSAGE RemoveAnchorsFromLinksRespond server->author
{
rc : rc_t;
};
SEQUENCE GetLinks server, author
MESSAGE GetLinks server->author, author->server
{
};
MESSAGE GetLinksRespond server->author, author->server
{
num_lnks : cardinal;
num_to_ancs : cardinal[num_lnks];
to_ancs : id_1d[num_lnks][num_to_ancs()];
num_from_ancs : cardinal[num_lnks];
from_ancs : id_1d[num_lnks][num_to_ancs()];
};
Context services. A client may wish to open, close, create, delete, or modify contexts. These services are implemented with the "RequestService" message of the current protocol. A browser may request the identifiers of all opened and closed contexts. In this case, the browser supplies a list of context ids. The state for these contexts is returned. If the number of contexts in the set the browser initially supplies is negative, the array is ignored, an the state of all contexts is returned.
SEQUENCE OpenContexts browser
MESSAGE OpenContexts browser->server
{
num_ctxs : cardinal;
ctx_ids : id_1d[num_ctxs];
};
MESSAGE OpenContextsRespond server->browser
{
num_ctxs_opened : cardinal;
opened_ctx_ids : id_1d[num_ctxs_opened];
rc : rc_t;
};
SEQUENCE CloseContexts browser
MESSAGE CloseContexts browser->server
{
num_ctxs : cardinal;
ctx_ids : id_1d[num_ctxs];
};
MESSAGE CloseContextsRespond server->browser
{
num_ctxs_closed : cardinal;
closed_ctx_ids : id_1d[num_ctxs_closed];
rc : rc_t;
};
SEQUENCE GetContexts browser
MESSAGE GetContexts browser->server
{
num_ctxs : integer;
ctx_ids : id_1d[num_ctxs];
};
MESSAGE GetContextsRespond server->browser
{
num_open_ctxs : cardinal;
open_ctx_ids : id_1d[num_open_ctxs];
num_closed_ctxs : cardinal;
closed_ctx_ids : id_1d[num_closed_ctxs];
rc : rc_t;
};
SEQUENCE CreateContexts author
MESSAGE CreateContexts author->server
{
num_ctxs : cardinal;
num_lnks : cardinal[num_ctxs];
lnks : id_1d[num_ctxs][num_lnks()];
};
MESSAGE CreateContextsRespond server->author
{
rc : rc_t;
};
SEQUENCE DeleteContexts author
MESSAGE DeleteContexts author->server
{
num_ctxs : cardinal;
num_lnks : cardinal[num_ctxs];
lnks : id_1d[num_ctxs][num_lnks()];
};
MESSAGE DeleteContextsRespond server->author
{
rc : rc_t;
};
SEQUENCE AddLinksToContexts author
MESSAGE AddLinksToContexts author->server
{
num_ctxs : cardinal;
num_lnks : cardinal[num_ctxs];
lnks : id_1d[num_ctxs][num_lnks()];
};
MESSAGE AddLinksToContextsRespond server->author
{
rc : rc_t;
};
SEQUENCE RemoveLinksFromContexts author
MESSAGE RemoveLinksFromContexts author->server
{
num_ctxs : cardinal;
num_lnks : cardinal[num_ctxs];
lnks : id_1d[num_ctxs][num_lnks()];
};
MESSAGE RemoveLinksFromContextsRespond server->author
{
rc : rc_t;
};
Computation services. This message models client and server side computation. It is analogous to the "Interpret" message of the current protocol. Instead of the ability only to send scripts, a "program identifier" can also be sent, indicating that the recipient of the message should retrieve the program from the appropriate storage engine and execute it.
SEQUENCE Execute all
MESSAGE Execute all->all
{
pgm_id : id_t;
script : script_t;
lang : NTstring;
num_tags : cardinal;
tags : NTstring_1d[num_tags];
tag_vals : NTstring_1d[num_tags];
};
MESSAGE ExecuteRespond all->all
{
rc : rc_t;
};
Bidirectional "services". For completeness, and to address the bi-directional messages in the current proposal, these messages are included. However, because they are so general, the group should decide if they are necessary, or if these cases can better be handled otherwise (e.g., return codes for the "Error" message and new Sproc definitions for the "Other" message).
SEQUENCE Error all
MESSAGE Error all->all
{
error_name : NTstring;
error_text : NTstring;
num_tags : cardinal;
tags : NTstring_1d[num_tags];
tag_vals : NTstring_1d[num_tags];
};
SEQUENCE Other all
MESSAGE Other all->all
{
num_tags : cardinal;
tags : NTstring_1d[num_tags];
tag_vals : NTstring_1d[num_tags];
};
Contents
Top
1. Introduction
2. Scope of the OHSWG...
3. Scenarios...
4. An OHS Reference Architecture Proposal...
5. An OHP Proposal
6. Metacommentary
7. Conclusions
References
Appendix A. Generic Encoding Layer Rules
Appendix B. Sproc Generic Layer Rules
Appendix C. Sproc Specific Layer Rules
Appendix D. Sproc Interface Format
Appendix E. Current Protocol Proposal in Sproc Interface Format
Peter J. Nürnberg, John J. Leggett