|A Vision for Open Hypermedia Systems||Nürnberg and Leggett|
Before naming is discussed any further, it is important to note why this is even an issue that we should consider. The automatic indexer scenario summarized in Section 3.1 describes a program that indexes node content against the node identifier for all nodes served by a set of servers. If nodes cannot be uniquely identified, such an index cannot be built, or rather, even if it were, it would not be useful. If the group sees the automatic indexer scenario as a reasonable use of an OHSWG system, the issue of object naming must be addressed.
Naming objects is crucially important in a distributed system. It is beyond the scope of this paper to describe fully the intricacies or review the applicable work in this area (e.g., distributed file systems [Gifford et al. 1992; Reiher et al. 1994; Sun 1995; Többicke 1994], distributed operating systems [Walker et al. 1992; Welch 1994], and many other WWW or internet based initiatives [IETF 1997; OCLC 1997]). We wish to raise this issue, however, and outline the way in which one of the systems represented in the OHSWG (HOSS) is addressing this issue in order to provide a starting point for discussion.
HOSS object identifiers consist of two parts: a global identifier and a local identifier. The global identifier uniquely specifies a hyperbase. Hyperbases must be uniquely named. The method for generating globally unique hyperbase names may be handled in various ways. HOSS uses a completely distributed naming authority scheme which does not guarantee uniqueness. However, cost of name generation is very low and likelihood of collision can be made arbitrarily small. Theoretically, when a hyperbase is created, it generates a "random" 64 bit string which it uses as its identifier. In practice, the hyperbase creation script appends the least four significant bytes of the system time on the machine on which the hyperbase is being created to the IP address of that machine. The actual method of generating these 64 bits (or even the number of bits in this global identifier) is not relevant to the idea. A "DNS-like" naming authority scheme that guarantees uniqueness [Albitz and Liu 1996], a global registry of available names, or other methods could be used as well.
The local part of an object identifier is assigned by the hyperbase management system (HBMS) itself. It may be any size, so the number of objects in a hyperbase, the way in which an HBMS names objects, etc. are unconstrained. The HBMS must be able to guarantee uniqueness over the local identifiers it generates for a particular hyperbase.
Whether or not the OHSWG adopts this object naming scheme, another well-established scheme, or defines its own, this issue should be addressed. In this paper, we do not propose any particular object naming procedure. We simply note that the above method seems sufficient and may provide a starting point for discussion among group members.
With respect to server naming, this issue only arises when multiple servers are defined. Our reference architecture proposal describes an open set of structure servers ("link server", "composite server", "spatial hypertext server", etc.) Each of these servers must have a unique name.
In HOSS, server naming authority is completely distributed and works on a global registry basis. Servers register any name (or set of names) they wish with a global name registry, along with ports on which the server is listening for service requests. Programs may query this registry to locate particular servers. (This incidentally brings up the issue of locating servers in a distributed environment as well. This issue, although important, is not addressed in detail here.) The global registry is effected as a distributed set of name information managers (called SIM's, see Section 4.1.1) that propagate information among themselves. SIM's are arranged hierarchically. Name requests that cannot be resolved at one SIM may be propagated up the hierarchy and to the appropriate SIM in a way analogous to the resolution of machine names to addresses in DNS [Albitz and Liu 1996].
As with object naming, it is outside of the scope of this paper to propose a specific method for doing server naming. However, if the OHSWG adopts an open set of servers in its reference architecture, this will have to be addressed. The above method seems adequate, and should provide a starting point for further discussions.
2. Scope of the OHSWG...
3.1 Scenario Synopses
4. An OHS Reference Architecture Proposal...
3.2 Scenario Implications
5. An OHP Proposal...
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