in Information and Computer Science

0 downloads 0 Views 1MB Size Report
Chimera's hypermedia model is similar to Dexter in that its notion of a client parallels ...... Leslie Carr, Gary Hill, David De Roure, Wendy Hall, and Hugh Davis.
UNIVERSITY OF CALIFORNIA, IRVINE

Pervasive Hypermedia

DISSERTATION

submitted in partial satisfaction of the requirements for the degree of

DOCTOR OF PHILOSOPHY

in Information and Computer Science

by Kenneth M. Anderson

Dissertation Committee: Professor Richard N. Taylor, Chair Professor Jonathan Grudin Professor Pedro Szekely 1997

© Kenneth M. Anderson, 1997. All rights reserved.

The dissertation of Kenneth M. Anderson is approved and is acceptable in quality and form for publication on microfilm:

____________________________________ ____________________________________ ____________________________________ Committee Chair

University of California, Irvine 1997

ii

DEDICATION

To

my parents and their parents

their love, hard work, and emphasis on education

made this dissertation possible

Also

to my wife

Leysia

with Love

iii

TABLE OF CONTENTS Page LIST OF FIGURES

vii

LIST OF TABLES

viii

ACKNOWLEDGMENTS

ix

CURRICULUM VITAE

x

ABSTRACT OF THE DISSERTATION

xii

INTRODUCTION

1

CHAPTER 1: Exploratory Systems 1.1 Chimera 1.0 1.1.1 Hyperbase vs. Link Server 1.1.2 Open vs. Closed Hypermedia Model 1.1.3 Client Characteristics 1.2 Chimera 2.0 1.3 Toolkit Integration Technique 1.3.1 Entry Barrier vs. Quality vs. Applicability 1.3.2 Separation of Concerns vs. All-In-One

8 8 12 14 15 16 24 27 28

CHAPTER 2: Related Work 2.1 Open Hypermedia Systems 2.1.1 ABC 2.1.2 DHM 2.1.3 Hyperform 2.1.4 HyperDisco 2.1.5 Microcosm 2.1.6 Multicard 2.1.7 SBx/HBx 2.2 OHS-WWW Integration 2.2.1 OHS Data to WWW Data 2.2.2 WWW Client as OHS Client 2.2.3 WWW Server as OHS Client 2.2.4 Hybrid Integrations 2.2.5 OHS Server as WWW Server 2.2.6 WWW Protocols Within an OHS 2.3 Hypermedia Infrastructure 2.3.1 Hypermedia Toolkits 2.3.2 Open Hypermedia Systems 2.3.3 Groupware Toolkits 2.3.4 Alternative Integration Techniques

30 30 33 36 39 41 44 45 46 49 49 50 51 53 54 55 56 56 57 58 59

iv

CHAPTER 3: Support for Heterogeneity 3.1 Chimera’s Hypermedia Concepts 3.1.1 Evolution of Concepts 3.2 Separation of Client and Viewer 3.2.1 Client Responsibilities 3.2.2 Viewer Responsibilities 3.3 Dynamic Link Semantics 3.4 Multi-Platform Support 3.5 Multi-Lingual APIs 3.6 Incremental Adoption

62 64 68 70 71 72 73 75 76 80

CHAPTER 4: Integration with the WWW 4.1 WWW-OHS Integration Conceptual Architecture 4.1.1 User Environment 4.1.2 Web Environment 4.2 WWW-OHS Integration Implementation Architecture 4.2.1 Applying the Implementation Architecture to Chimera 1.0 4.2.2 Implementation Details 4.2.3 Support for Web-Based Clients 4.2.4 Implications

82 83 83 86 89 91 93 94 99

CHAPTER 5: Integration of User-Interface Toolkits 5.1 Toolkit Integration Technique 5.1.1 Extended Widgets 5.1.2 Hypermedia Infrastructure 5.1.3 Plug-and-Play Issues 5.2 Implementation Issues 5.2.1 Prototype Implementations 5.2.2 Integrated Container Widget 5.2.3 Implementation of the Hypermedia Infrastructure

v

101 103 104 107 109 111 111 114 115

CHAPTER 6: Validation 6.1 Client Integration Framework 6.2 Integrated Chimera Clients 6.2.1 FrameMaker 3.1 6.2.2 Chimera Shell 6.2.3 XEmacs 6.2.4 Xvi 6.2.5 XGif 6.2.6 Xmpeg 6.2.7 Sound Player 6.2.8 Flight Simulator 6.2.9 Chimera Presence Applet 6.2.10 Mail Client Demo 6.2.11 Spreadsheet Demo 6.3 Validation Matrix 6.4 Impact on Community

118 119 123 124 126 126 127 128 129 130 130 131 132 133 134 139

CHAPTER 7: Future Work 7.1 Open Issues in Open Hypermedia Systems 7.1.1 Exposing Server APIs 7.1.2 Server-To-Server Communication 7.1.3 Increased Support for Web Applications 7.1.4 Providing Services to the WWW 7.2 Open Issues in TI Technique 7.2.1 Proof-of-Concept Prototypes 7.2.2 Transparency 7.2.3 Scalability

141 141 142 146 147 149 150 150 151 152

CHAPTER 8: Conclusions

155

REFERENCES

160

APPENDIX A: Chimera Application Program Interface

167

vi

LIST OF FIGURES Page Figure 1-1.

Chimera 1.0’s Conceptual Architecture

10

Figure 1-2.

Chimera 2.0’s Conceptual Architecture

19

Figure 1-3.

The Toolkit Integration Technique’s Conceptual Architecture

25

Figure 3-1.

Chimera’s Hypermedia Concepts.

65

Figure 4-1.

OHS-WWW Integration Conceptual Architecture.

84

Figure 4-2.

OHS-WWW Integration Implementation Architecture.

89

Figure 4-3.

Interactions within the Implementation Architecture.

94

Figure 4-4.

The Chimera Presence Applet.

95

Figure 4-5.

Applet Interactions within the Implementation Architecture.

96

Figure 4-6.

Output of the Chimera Presence CGI Script.

98

Figure 5-1.

The Conceptual Architecture of the Integrated Toolkit.

105

Figure 5-2.

The Conceptual Architecture Modified to Highlight Reuse Issues.

109

vii

LIST OF TABLES Page Table 6-1.

Coverage and Validation Matrix Based on Chimera’s Clients (Part 1) 135

Table 6-2.

Coverage and Validation Matrix Based on Chimera’s Clients (Part 2) 136

Table 6-3.

Coverage and Validation Matrix Based on Chimera’s Clients (Part 3) 137

Table 8-1.

Summary of Requirements for Large-Scale Information Environments 157

viii

ACKNOWLEDGMENTS

I have a deep respect for my advisor (and committee chair) Professor Richard N. Taylor. He has fostered within me a love of research, a critical eye for quality, and the desire to explore “just one more” issue or trade-off. I have had the opportunity to work in an excellent research environment with ample resources, interesting colleagues, and no distractions about how the rent would be paid! During the past nine years, I have gained valuable insights into the nature of research, the politics of research funding, and the benefits of collaboration. He has given me a set of skills upon which I can confidently build a professional career. Professor Jonathan Grudin has provided me with several very interesting classes while here at UCI which helped to broaden my view of the HCI and CSCW fields. In addition, he has always been available to provide his insights on a variety of issues both professional and personal. Professor Pedro Szekely taught me an important lesson soon after meeting him on a train trip from Rome to Sorrento Italy. We were both participants at a workshop organized by my advisor. The workshop was discussing a potential solution for an issue which had obvious shortcomings. Despite this, the group was mainly focused on getting the solution to work however ineptly. This continued until Pedro raised his hand and said “I do not think this will work.” and then proceeded to state why. This ability to “go against the grain” of a discussion and then argue intelligently about the shortcomings made quite an impression on me. It is something I am still learning to do with the same confidence demonstrated by Pedro. The past three years of my life have been especially wonderful ever since I met the woman who became my wife. Leysia has filled my life with happiness, love, and meaning. She has also provided the critical support needed to keep me focused on finishing this document. I look forward to sharing the rest of my life with her. My family and friends have always provided love and support over the last eleven years of undergraduate and graduate schools. My achievements and desire to persevere were enabled by this unshakable foundation. Finally, in a very real sense, my research would not have been possible without the research funding provided by the United States Federal Government. My research was initially sponsored by the Advanced Research Projects Agency under Grant Number MDA972–91–J– 1010. It is now supported by the Air Force Materiel Command and the Advanced Research Projects Agency under Contract Number F30602-94-C-0218. The content of the information does not necessarily reflect the position or the policy of the Government and no official endorsement should be inferred.

ix

CURRICULUM VITAE

1988-90

Undergraduate Honors Program, University of California, Irvine

1988-90

Undergraduate Fellowhip, Unisys Corporation

1990

Summer Internship, User-Interface Group at Unisys Corporation

1990

B.S. in Computer Science, University of California, Irvine

1990

Member of Phi Beta Kappa

1990-91

Teaching Assistant, Department of Information and Computer Science, University of California, Irvine

1991-97

Research Assistant, Program in Software, Department of Information and Computer Science, University of California, Irvine

1992

M.S. in Computer Science, University of California, Irvine

1993

Summer Internship at IBM Federal Systems Division

1997

Ph.D. in Information and Computer Science, University of California, Irvine Dissertation: “Pervasive Hypermedia” Professor Richard N. Taylor, Chair

PUBLICATIONS Refereed Journal Publicaitons Taylor, R. N., Nies, K. A., Bolcer, G. A., MacFarlane, C. A., Anderson, K. M., and Johnson, G. F. (1995). Chiron-1: A Software Architecture for User Interface Development, Maintenance, and Run-Time Support. In ACM Transactions on Computer-Human Interaction, Vol. 2, Num. 2, pages 105-144. Taylor, R. N., Medvidovic, N., Anderson, K. M., Whitehead, Jr., E. J., Robbins, J. E., Nies, K. A., Oreizy, P., and Dubrow, D. L. (1996). A Component- and Message-Based Architectural Style for GUI Software. In IEEE Transactions on Software Engineering, Vol. 22, Num. 6, pages 390-406.

x

Refereed Conference Publications Anderson, K. M., Taylor, R. N., and Whitehead, Jr., E. J. (1994). Chimera: Hypertext for heterogeneous software environments. In Proceedings of the ACM Conference on Hypertext, pages 94–107, Edinburgh, Scotland. Taylor, R. N., Medvidovic, N., Anderson, K. M., Whitehead, Jr., E. J., and Robbins, J. E. (1995). A Component- and Message-Based Architectural Style for GUI Software. In Proceedings of the 17th International Conference on Software Engineering, pages 295-304. Seattle, Washington, USA. Anderson, K. M. (1997). Extending User-Interface Toolkits with Hypermedia Functionality. In Proceedings of the 30th Hawaii International Conference on System Sciences. Wailea, Hawaii, USA. Anderson, K. M. (1997). Integrating Open Hypermedia Systems with the World Wide Web. In Proceedings of the ACM Conference on Hypertext, pages 157-166, Southampton, UK. Refereed Workshop Publications Anderson, K. M. (1996). Providing Automatic Support for Extra-Application Hypertext Functionality. In Proceedings of the Second International Workshop on Incorporating Hypertext Functionality Into Software Systems. Part of the 1996 ACM Conference on Hypertext. Washington D.C., USA. Anderson, K. M. (1997). A Critique of the Open Hypermedia Protocol. In Proceedings of the Third International Workshop on Open Hypermedia Systems. Part of the 1997 ACM Conference on Hypertext. Southampton, UK.

xi

ABSTRACT OF THE DISSERTATION

Pervasive Hypermedia by Kenneth M. Anderson Doctor of Philosophy in Information and Computer Science University of California, Irvine, 1997 Professor Richard N. Taylor, Chair

The heterogeneity of modern computing environments contributes to the information overload experienced by users. Relationships within and between applications, documents, and processes are often implicit and must be managed and tracked by the user. Hypermedia has been put forth as one approach to organizing these relationships, making them explicit so they can be managed. One approach to providing environment-wide hypermedia services is through the use of open hypermedia systems (OHSs). OHSs are open with respect to the set of systems and information over which hypermedia services can be provided. This research area contrasts with the original approach to hypermedia services that involved developing monolithic systems with a closed set of supported data types (e.g. HyperCard). Given the existence of OHSs, another area of research is developing integration techniques such that applications that existed before the introduction of an OHS can take advantage of the OHS’s hypermedia services. This dissertation provides contributions in both of these research fields.

xii

In particular, this work demonstrates techniques which enable OHSs to address the heterogeneity of their computing environments, to leverage the strengths of the World Wide Web (while providing the Web with improved hypermedia services), and to integrate large classes of applications at once. Heterogeneity is handled via a set of flexible abstract hypermedia concepts, application program interfaces in multiple programming languages, support for multiple operating systems, and a low entry barrier to use provided by an architecture designed to reduce the responsibilities of client applications. Integration with the Web is enabled via a scalable architecture for OHSs that is compatible with the Web’s architecture and takes advantage of the strengths of Web protocols and the familiarity of Web interaction styles. The integration of multiple applications occurs via a technique for making user-interface toolkits (and hence their constructed applications) clients of an OHS. This technique provides consistent inter- and intra-application hypermedia services.

The dissertation is validated by examining the characteristics of the clients integrated with the exploratory systems developed during the course of this research. The dissertation concludes by positioning this work within the context of large-scale information environments.

xiii

INTRODUCTION

Modern computing environments are composed of diverse operating systems, thousands of applications, gigabytes of information, and multiple users acting in groups or individually. This heterogeneity is both a strength and weakness. The complex tasks people use computers to solve demand diverse techniques and resources to solve. No single application, data type, or process will ever be sufficient to handle all of them. The diversity in computing platforms and their contents is thus a natural response to the realities of dealing with real-world problems. The price, of course, is incompatibility, low interoperability, conflicting techniques, and the constant perceived need of keeping up with the rapid pace of technological change. The victims of these problems are the users of these environments and their ability to perform work and achieve goals.

Enter hypermedia. The basic idea of hypermedia is to enable the rapid navigation of related chunks of information. The important notions inherent within this idea are nodes, anchors, and links, and the roles of author and reader. Nodes refer to the information being browsed, anchors indicate specific portions of the information, and links model the relationships between the regions of information singled out by the anchors. While the ability to browse and navigate a corpus of information is important to a user as reader, it is equally important in the domain of hypermedia for the user to act as author with the ability to create new anchors and links within and over the information. The network-like nature of the nodes and links has evolved the use of the term web or hyperweb to denote the entire set of structured information including both the corpus and the anchors and links. The hypermedia

1

2 community has produced a great body of research to refine these simple notions, define new techniques and services for the manipulation of hyperwebs, and explore the issues of hypertext rhetoric.

Regarding heterogeneity, a class of systems known as open hypermedia systems (OHSs) are designed to provide hypermedia services to the applications found in modern computing environments. Recently cataloged by Østerbye and Wiil [52], OHSs employ one of two techniques to achieve this goal. The first technique, the hyperbase approach, requires applications to store their content in a database, or hyperbase, controlled by the OHS. The OHS then offers a variety of hypermedia operations including traversal, anchor and link manipulation, and search and query over the content stored in the hyperbase. The second technique, the link server approach, evolved in response to the restriction inherent in the former technique. Namely, not all applications can participate in a hypermedia system which imposes a requirement on where data is stored. For instance, legacy systems would not only have to be modified to read and write from the database but all of the system’s data would have to be transferred to the database as well. The high costs associated with such an effort prevented a large class of existing applications from adopting the hypermedia services of hyperbase systems.

Link servers, on the other hand, place no restrictions on the data storage of client applications. Instead, they provide an application program interface (API) to their hypermedia operations and store in their database only a model of the external world (in terms of nodes and anchors) and the relationships (or links) which exist in the model. While existing

3 applications must still be modified to make use of the API, the extra step of transferring its data into the OHS’s database is avoided. This reduces the developmental effort of the task and thus increases the range of applications willing to integrate with link server systems. Finally, some systems are starting to employ both techniques. For instance, HyperDisco [72] provides its clients with a choice of storing their content internally in the hyperbase or externally in the file system. The penalty for storing content outside the hyperbase is that some advanced features, such as the versioning of content, anchors, and links, are unavailable.

The question of integration is a key concern of OHSs. Integrating new applications is easy for both approaches since, during the design of the application, the developers simply make use of the API and, for the former approach, hyperbase. It is the goal of integrating existing applications which is difficult, and thus a suite of integration techniques has been developed by the OHS community. Another important concept related to these techniques is the notion of levels of service. The idea here is that the characteristics of an application and the integration technique used to integrate it will determine the type of hypermedia services it can provide to its users. Some techniques may be able to achieve higher levels of service than others. Davis, et al. [15] reports on early work in this area. Whitehead [67] further refines the area with a framework designed to model an application before and after an integration attempt and provides some techniques for predicting the level of service an application will achieve once integrated.

This dissertation presents new results in the OHS field: techniques for supporting heterogeneity and integration with the World Wide Web and a novel integration technique

4 which focuses on the infrastructure upon which most applications depend rather than on the applications directly. Specifically, the contributions of this work are as follows:



Support for Heterogeneity. In order to deal with the diversity of modern computing environments, an OHS must employ a variety of techniques. Unique to this dissertation is the use of the following techniques in tandem: support for multiple programming languages, support for multiple operating systems, use of flexible conceptual abstractions, support for user-defined link semantics, minimal client architecture assumed, and a low entry barrier to use. The Chimera open hypermedia system [2] serves as a vehicle for exploring the benefits and trade-offs of these techniques.



Views as First-Class Objects. A strict separation of anchors from their associated objects is required in order to support a wide range of data types and provide hypermedia access to information without modifying it. The abstraction of a view achieves this separation. In a nutshell, viewers create views of an object, and anchors are associated with these views rather than with the objects directly. Experience with the Chimera OHS has demonstrated the utility of this conceptual model with real-world clients. This research is unique in promoting the notion of a view to a first-class conceptual object within an OHS. Views are persistent between run-time sessions and have a set of associated operations.



Viewer-Client Distinction and Multiple APIs. A clear demarcation of the concepts of clients and viewers allows an OHS to support a wide range of client application

5 architectures. In addition, the provision of the OHS’s API in multiple programming languages makes the OHS more accessible to client applications. This research is unique in applying these techniques in tandem within an OHS. While the latter technique appears minor, all other hypermedia systems either provide an API for only one programming language, or worse, provide just the details of the socket protocol used, placing the onus on the client developer to implement the protocol.



Integration with the WWW. The World-Wide-Web (WWW) [6, 8] is the largest distributed hypermedia system in use today. It offers standard protocols and data formats, cross-platform availability, global content distribution and linking, and a low-entry barrier to use. These features made it enormously popular and globally adopted. However, it was designed and implemented almost entirely separate from the existing hypermedia literature! As a result, the OHS community has sought ways in which to integrate their systems with the WWW in order to augment the capabilities of the Web. This dissertation presents a novel perspective on the issues of integration by exploring the benefits gained by integrating the WWW into an OHS. A new version of Chimera [5] explores techniques such as using URLs to locate servers, websites, and hyperwebs and using HTTP to directly access API operations on an OHS server. Hyperwebs are stored under a WWW server’s namespace and are hierarchically composable. Finally, standard Web interaction techniques are reused within the OHS allowing users to leverage their experience with the Web in learning and using the OHS.

6 •

User-Interface Toolkit Integration Technique. The user-interface toolkit integration technique (TI Technique) enables hypermedia services in client applications by integrating their user-interface (UI) toolkit with an OHS [4]. Since the UI toolkit is a client of an OHS, its widgets have access to hypermedia services. Each widget can construct hypermedia structures that model its hypermedia needs and then provide access to services such as anchor manipulation and link traversal. Two toolkits have been integrated with Chimera in this fashion, and provide insight on how the architectural features of the toolkits impact the quality of the final integration. The focus on infrastructure with this technique is a more promising route of integrating client applications since, once complete, multiple applications benefit.



Integrated Container Widget as Whole-Component Anchor. Within the context of the TI technique, an extended container widget enables the rapid integration of existing applications at a basic level of hypermedia service. This integration-technique-within-anintegration technique is made possible by the nature of a container widget. A container widget typically lays out one or more user-interface widgets within its boundaries. This establishes a hierarchy of widgets with special semantics for event handling. If the container widget is “hypermedia-aware”, it can act as an anchor for whatever is included within its boundaries. This class of anchor is known as a whole-component anchor [30, 31]. Thus, once an integrated container widget is available, any application which uses the user-interface toolkit can be integrated with an OHS at a basic level of service by simply including its entire user-interface within an integrated widget. The amount of effort to reparent an interface in this fashion is extremely low.

7 The remainder of the dissertation is organized as follows. Chapter 1 describes, at a high-level of detail, the systems used to explore my techniques (Chimera 1.0, Chimera 2.0, and the toolkit integration architecture). Its purpose is to enable the discussion of related work in Chapter 2. Chapters 3 then presents techniques for supporting heterogeneity. Chapter 4 discusses techniques which enable OHS integration with the WWW, and Chapter 5 describes the TI integration technique in detail. Chapter 6 focuses on the clients integrated with the experimental systems and how they validate the above contributions. Chapter 7 discusses future work followed by conclusions in Chapter 8.

CHAPTER 1: Exploratory Systems

My research method explores the utility of research techniques via the construction of software systems. The research described in this dissertation can be grouped into three different sets of techniques. The first set addresses the heterogeneity of modern computing environments. The second set deals with integrating open hypermedia systems with the World Wide Web. The final set examines reducing the effort associated with providing hypermedia services within the clients of an open hypermedia system. I have developed several systems to explore these techniques: Chimera 1.0, Chimera 2.0, and the prototype applications of the toolkit integration technique. The strength of this research approach is its ability to identify and illuminate design trade-offs. An increased understanding of the trade-offs inherent in a system, in turn, leads to improved designs for subsequent systems. This feedback loop is apparent in my work, as demonstrated by the evolution of Chimera 1.0 into Chimera 2.0 (discussed below).

This chapter presents a high-level description of the systems mentioned above. The focus in this chapter is on the architectural elements and the design trade-offs of each system. This discussion sets the stage for an examination of related work in the next chapter. The systems are presented in chronological order of development.

1.1 Chimera 1.0 Chimera 1.0 is an open hypermedia system tuned to the needs of software environments [2]. Chimera’s features and services are designed to handle the intrinsic

8

9 heterogeneity of these environments. In particular, Chimera defines a set of hypermedia concepts which are both general and flexible in modeling the hypermedia needs of client applications. Chimera’s principle concepts consist of viewers, objects, views, anchors, and links. Viewers are programs which allow users to browse and manipulate information of various types. Objects are information which can be manipulated by viewers. Views are the graphical depictions of objects created by viewers. Anchors refer to regions of interest within these views. Finally, links are sets of anchors. In addition, attribute-value pairs (or more simply, attributes) can be associated with any instance of any concept allowing clients the ability to augment the basic concepts with application-specific information. The remaining conceptual elements of Chimera are hyperwebs, which are persistent collections of Chimera’s hypermedia concepts along with their attributes, and clients which are executable programs which consist of one or more viewers. The distinction between client and viewer is necessary since they have separate responsibilities. It is often difficult to distinguish between the two in practice, however, since typically clients contain only one viewer.

This conceptual framework provides the basis for Chimera’s architecture (see Figure 11). The architecture consists of the following main elements: users, hyperwebs, clients, the process invoker, and the Chimera server.



Users. Multiple users can access a hyperweb at once. Each user has a of clients active in order to perform work. This set can change over time either by the user invoking or quitting applications directly or by the actions of the process invoker.

10

User Process Invoker

Client

Client

Client

User

Client

Chimera Server

Client

Process Invoker

Client

User

Process Invoker

External System

Persistent Hyperweb Storage

Communicates/Interacts

User

Sends Invocation Request Invokes User Space

Operating System Process

Viewer 1 Client Internals

Storage Mechanism

Viewer N Chimera API

Figure 1-1. Chimera 1.0’s Conceptual Architecture Chimera employs a client-server architecture. Each user has a set of Chimera clients running in a distinct user space. These clients are typically interactive, although that is not a requirement, and consist of one or more viewers running in separate threads. Clients communicate with the Chimera server through the Chimera API to gain access to the currently active hyperweb. Clients may also interact with external systems in a user’s environment. Each user may run a process invoker which can activate clients needed to complete link traversals. The process invoker receives an invocation request from the server and maps the requested client to an executable in the user’s environment. It then invokes the specified executable using operating system services.



Hyperwebs. Hyperwebs consist of a model of the user’s environment and the relationships established over the information contained within that environment.



Clients. Clients provide browsing and editing operations on a variety of data types as well as hypermedia operations such as anchor creation and link traversal. These applications contain one or more viewers (each viewer specializing in the display of a specific data type) and a linked library of routines known as the Chimera API. The Chimera API encapsulates the code necessary to perform inter-process communication with the

11 Chimera server and provides access to Chimera’s hypermedia operations. It also provides a mechanism for the client to register event handlers for Chimera’s hypermedia events which are generated asynchronously by the Chimera server. A Chimera client participates in the Chimera protocol by invoking the appropriate API operations during initialization and in response to user actions and correctly handling the events it receives from the Chimera server.



Process Invoker. The process invoker is responsible for automatically invoking clients needed to complete a link traversal. This situation occurs when a link traversal ends in a view managed by a viewer which is currently not executing or managed by a viewer which is executing but can only handle one view at a time. This situation is known as a delayed link traversal, since the traversal is delayed while waiting for the newly invoked client to initialize. Once the client signals the Chimera server that it is ready to receive events, the server forwards the link traversal event to it for handling. The use of a process invoker is discretionary. If the user does not invoke the process invoker, then all delayed link traversals are discarded.



Chimera Server. The chimera server has three key duties. The first responsibility is the persistence and manipulation of Chimera hyperwebs. The server implements the operations of the Chimera API and ensures that the changes made by viewers persist between invocations of the server on a particular hyperweb. The access to a hyperweb is centralized; only one server can manage a hyperweb at a time. The second responsibility is to track the current state of the world which consists of the active set of users accessing the

12 hyperweb, their clients, and the viewers and views currently active within each client. This latter information enables the server to correctly route link traversal events and detect the need for delayed link traversals. Finally, the third responsibility is to generate hypermedia events as they occur and send them to all clients which have registered an interest in them.

The trade-offs explored in Chimera’s design are all variations of one general theme: open vs. closed. Before discussing the trade-offs, a definition of open and closed is helpful. Being open in system design means minimizing the assumptions made about the external world. As the number of requirements placed on the entities interacting with the system decreases, the range of potential participants increases. However assumptions enable increased quality of service and performance optimizations for entities which meet the assumed requirements. Thus, a delicate balance in the open and closed aspects of a system is required to ensure a wide range of clients while at the same time providing (at the very least) an acceptable level of service. With this in mind, the trade-offs considered in the design of Chimera 1.0 are presented below.

1.1.1 Hyperbase vs. Link Server The most important decision considered during the design of Chimera 1.0 was whether to require clients to store their information in a database under Chimera’s control. The trade-off here is one of consistency and increased service verses the developmental effort required to engineer applications to use the hyperbase as an information repository.

13 As to the former, if the hypermedia system is in control of all the content then it is able to ensure consistency in the face of change as the information is updated. If a file is modified, the hyperbase can easily track the changes made to anchors by comparing the document to previous versions. In addition, the quality of service a hypermedia system provides increases due to the tight coupling with its clients and the fact that the hyperbase can be indexed to ensure rapid link traversals, search, and queries [60]. The downside to this approach is that developers may not wish to expend the effort required to achieve a tight integration with the hyperbase, and in the case of legacy and third-party systems, the source code may not be available to do the integration in the first place [2].

The alternative to the hyperbase approach is the link server approach which stores only anchors and links in the database and interacts with clients via an API [54]. In contrast, this approach has a loose coupling with its clients, since a client can choose to use only the bare minimum of API operations to enable link traversal and forego other, more advanced, operations. In fact, of the ninety or so operations of the Chimera API only a handful are required to achieve this type of minimal integration. There are still responsibilities for client applications to meet however they are not of the same profound nature as the requirements of the hyperbase approach. This increases the range of clients which can be integrated with the hypermedia system. This includes a variety of third-party and legacy systems which can be integrated via a range of techniques. Chimera 1.0 adopted the link-server approach in its implementation.

14 1.1.2 Open vs. Closed Hypermedia Model The hypermedia model of a system is the set of concepts it uses to map abstract notions of anchor, node, and link into the concrete representations used by its clients. Some systems enable clients to define new models or extend existing ones to provide applicationspecific behavior [70]. Other systems define one set of concepts which must be used by all applications. The trade-off here is extensibility verses generality.

Extensibility is considered a good attribute in system design. It acknowledges that a designer will not be able to fully anticipate the needs of the system’s users and provides a mechanism for the end-users to customize the system to suit their needs. Extensibility comes with a price, however, in increased system complexity since extensibility mechanisms must be designed and implemented and also in the potential for users to make incompatible customizations which hinder interoperability between the system’s clients. For instance, defining a new hypermedia model may render the existing algorithm for link traversal inapplicable, thus forcing the user to implement a new algorithm which appropriately handles the customizations. In addition, clients which use the default model may not be able to link with the new model, or do so in an unsatisfactory manner.

On the other hand, designing a single general model for all clients enables the provision of algorithms tuned to the structure of the model. There is no danger of incompatibilities since all clients use the same model. The downside to this approach is that for some applications the model may not map appropriately causing the developer to use the model in unintended ways. In addition, it is less easy to change the model since drastic

15 modifications would impact all clients. In spite of this, Chimera 1.0 adopted this approach with its hypermedia model. Steps were taken to minimize the disadvantages just listed. First, the notions and relationships between viewer, object, and view are found in many software applications and thus have a wide range of applicability. Second, as shall be seen in Chimera 2.0, the model can be extended in various ways to enable new concepts and functionality without disrupting existing clients. The key is to make small extensions while maintaining existing functionality.

1.1.3 Client Characteristics Some hypermedia systems make assumptions about the clients which interact with them which limit the openness of the system. Common assumptions of this nature include the choice of operating system, the programming language used, or the communication protocol between client and server. The trade-off here is what is an acceptable set of assumptions, or what client characteristics can or can not be abstracted away.

Chimera adopted a two-fold strategy to deal with this trade-off. First, a clear demarcation between the concept of client and viewer was made. No client architecture was assumed, however clients were defined as containing one or more viewers. This enabled Chimera to handle the traditional single-threaded client while supporting multi-threaded clients which could have multiple viewers active at once. This separation between clients and viewers enabled the definition of distinct responsibilities for each concept. This definition, in turn, allowed Chimera to assume only that a client must meet its responsibilities and ignore all other characteristics. The second part of Chimera’s strategy now comes into play. In order

16 to abstract away platform- and language-specific issues, Chimera defined its API in a language-independent manner and then provided implementations of the API in multiple programming languages. The duty of implementing Chimera’s communication protocol was placed on the API implementations thus freeing Chimera clients from that responsibility.

1.2 Chimera 2.0 Chimera 2.0 [5] explores integration issues between open hypermedia systems and the World Wide Web (WWW). The WWW is a globally-distributed extensible hypermedia system [8]. It gains these features via the use of three key standardized protocols: HTTP [19], HTML [7], and URL [9]. HTTP specifies the communication protocol between clients and servers. HTML defines the hypermedia model of the WWW and serves as the primary format for content. URLs are a standard way to locate resources on a global-scale. Due to these standards, software for the Web quickly appeared on multiple platforms and the entry barrier to use was extremely low. These factors made the Web enormously popular and it experienced wide-spread adoption in 1995 and 1996. In turn, this popularity coupled with the deficiencies (from the standpoint of hypermedia researchers) of the Web, motivated interest in integrating open hypermedia systems with the WWW [5, 12, 28]. As will be seen in the next chapter on related work, most work in this area has as its goal improving the hypermedia services of the Web. Chimera 2.0 explores the integration in the other direction, i.e., how can the WWW improve the hypermedia services of an OHS.

With respect to Chimera 1.0, the WWW is interesting since the Web made different choices with respect to two of the trade-offs listed in the previous section. For instance,

17 establishing HTML as the primary format for content is similar to adopting a hyperbase approach to providing hypermedia services. The content is not stored in a single controlled database, however in order to receive hypermedia services from within WWW clients an application’s content must be stored in the HTML format. HTML, in addition, defines an extensible hypermedia model. The WWW browser wars exhibit the problems described in the previous section concerning incompatible extensions to the model. The combined standards enable the abstraction of client characteristics similar to Chimera 1.0, in that the only assumption made about the client is that it must meet the requirements of the standards.

Another interesting aspect of the Web is it makes explicit an implicit trade-off that was made in Chimera 1.0’s design. This trade-off is global distribution verses localization. Chimera 1.0 never explicitly included support for distribution in its design. In retrospect, it is thus not surprising that Chimera 1.0’s support for distribution is limited to a local-area network (LAN). In particular, the Chimera server, the process invoker, and users’ Chimera clients all could execute on different machines but they all required access to the same file system. The reason for this requirement lies in the fact that the rules for storing hyperwebs, specifying the active hyperweb, and locating the Chimera server were developed in an ad-hoc fashion.

In particular, hyperwebs could be stored in any valid directory in the file system. A configuration file, located in the user’s home directory, pointed to the active hyperweb by specifying its complete pathname. The Chimera server used this information to locate the hyperweb’s persistent files as well as to store its own file of connection information. Clients

18 located servers by reading first the configuration file to locate the active hyperweb and then the server file to obtain its connection information.

This arbitrary manner for storing hyperwebs made it difficult for users to discover the location of hyperwebs made by other users. Thus, there was little sharing of hyperwebs among Chimera 1.0’s users. In addition, since the Chimera server could only access one hyperweb at a time, and Chimera servers had no means of communicating between themselves, there was no way for users to create links between hyperwebs. This forced users to store all of their links and other hypermedia information in a single hyperweb rather than being able to group related anchors and links in logically and physically distinct hyperwebs. This restriction reinforced the localized nature of Chimera; there simply were no mechanisms in place to support the distribution of hyperwebs.

Chimera 2.0 evolves Chimera 1.0’s design to explore the other side of this trade-off. Since a complete redesign of the system would have been too costly, the protocols and mechanisms of the Web are leveraged to more rapidly incorporate support for the global distribution of hyperwebs into Chimera. The evolved architecture now makes a clearer distinction between the user’s environment and the environment used to store hyperwebs. In addition, the conceptual architecture has some additional elements (See Figure 1-2). The complete set of elements includes users, clients, Web browsers, applets, the Chimera server, WWW servers, cgi-scripts, hyperwebs, the hyperweb manager, and the hyperweb server.

19

User space Client

Client

Applet Web Browser

Chimera-enhanced websites WS HWM

CGI scripts Applets Hyperwebs

HWS Client

CS

CS

Chimera Server

HWM

Hyperweb Manager

HWS

Hyperweb Server

WS

WWW Server

CS

Figure 1-2. Chimera 2.0’s Conceptual Architecture The architecture is divided between a user’s computing environment and globally-distributed Chimeraenhanced websites. Chimera hyperwebs are now located only on these websites and, in particular, within a WWW server’s namespace. This associates with the hyperweb a URL which can be used to refer to it. The original Chimera server has been split into two servers, once which takes on its predecessor’s name and the other called the hyperweb server. The Chimera server is typically located in the user’s environment and it provides the user with an interface to connect to Chimera-enhanced websites and select among the hyperwebs located on these sites. In addition, it tracks the Chimera clients executing in a user’s environment and provides them access to the hyperwebs selected by the user. Chimera servers also execute on the websites in order to handle the requests of Chimera Java applets. Java restricts applets such that they can only communicate to server’s located on the machine from which they were downloaded. The hyperweb server takes on the responsibility of manipulating hyperwebs in response to client requests and ensuring the persistence of hyperwebs on its site. The hyperweb manager is a new server which is used to track the connection information of the server’s running on its site along with providing operations to create, delete, and rename hyperwebs. The WWW server can be configured with Chimera-related CGI-scripts which allow a user to browse hyperwebs and configure Chimera’s services from within a standard Web client.



Users and clients. Each user has a computing environment explicitly defined as a localarea network of machines with a shared file system. User’s clients, along with other elements of the Chimera 2.0 architecture, can execute on any machine within the LAN. The shared file system allows these clients to locate the Chimera server (discussed below) in a manner similar to Chimera 1.0. These clients then gain access to remote hyperwebs via this local Chimera server.



Web browsers and applets. Web browsers are now part of the architecture since they can be used to browse Chimera hyperwebs and access and configure Chimera servers located

20 on remote websites. In addition, applets can be downloaded into Java-enabled Web browsers and act as Chimera clients providing access to Chimera’s services. These applets are different from ordinary Chimera clients since they cannot access the local Chimera server but rather must access a remote Chimera server located on the site from which the applet was downloaded. This difference is due to the security restrictions Java places on its applet mechanism. The consequence is that Chimera clients executing as Java applets are not in synch with the reset of a user’s Chimera clients with respect to the hyperwebs they access. This is because there is currently no mechanism for a Chimera server handling requests from applets to connect to the applet’s user’s local Chimera server.



Chimera server. The Chimera server is similar to its predecessor in that it tracks the clients active in its environment, handles client requests, routes events, and implements link traversal. Clients locate a Chimera server using a strategy similar to the server connection information file of Chimera 1.0’s Chimera server. The difference in this case is that the information file is located in the user’s home directory. Chimera 2.0’s Chimera server differs from its predecessor in that it presents a user-interface to the user which provides operations to connect to remote sites and select among the hyperwebs stored at these sites. When the user selects a hyperweb, this hyperweb becomes shared by all of the Chimera server’s clients. In addition, the responsibilities of Chimera 1.0’s process invoker is now assumed by Chimera 2.0’s Chimera server. Finally, the Chimera server no longer manipulates hyperwebs directly nor does it manage their persistence. Instead, the management of hyperwebs is now handled by the hyperweb server (discussed below). This new separation of responsibilities enables the Chimera server to focus strictly on the needs

21 of its clients and take on new responsibilities such as the creation of links between hyperwebs. In Chimera 1.0, the Chimera server could not create links between hyperwebs because it was only allowed to access one hyperweb at a time. Now that there is a separate server to handle hyperweb management, the Chimera server can connect to multiple hyperweb servers and establish links which span hyperwebs.1 As noted above, the Chimera server also appears in the website environment. In this environment, the Chimera server’s role is to handle the requests of Chimera Java applets. It is important to note that once the applet is connected to a remote Chimera server, it is no longer restricted to accessing the hyperwebs located on the same machine from which it was downloaded. In fact, it can access any Chimera-enhanced website since it is the Chimera server which is making the connection on behalf of the applet. This allows Chimera Java applets to participate fully in the Chimera 2.0 world with the exception of the synchronization problem with other Chimera clients mentioned above.



WWW server and cgi-scripts. The WWW server plays a critical role in the Chimera 2.0 architecture. It associates a URL with the site as a whole and to the hyperwebs located on the site. This, in turn, addresses the problem encountered in Chimera 1.0 in which hyperwebs were arbitrarily scattered throughout the file system. In particular, hyperwebs are now stored in a pre-defined location with the document space of the server, for instance, . Users can now locate other hyperwebs more easily since they “know where to look.” Another important aspect of the WWW server is its ability to be augmented with cgi-scripts. In particular Chimera 2.0 cgi-scripts can

1. The process for creating links between hyperwebs is examined in detail in Section 4.2.1.

22 enable users to browse hyperwebs (by having the script connect to the local hyperweb server, retrieve the appropriate information, and convert it into HTML), configure Chimera 2.0 servers, or access Chimera-related site information all from within a standard WWW client.



Hyperwebs. In addition to their newly standardized location mentioned above, hyperwebs have received other improvements. First, hyperwebs are now hierarchical; any hyperweb can contain multiple subwebs. The URLs associated with each hyperweb make it simple to specify subwebs. For instance, the URL

accesses web1.1 which is a subweb of web1. Second, all hyperwebs on a site share

information about viewers, objects, and views. Thus, once a viewer registers with one web on a particular site, it does not have to reregister with any of the other webs on that site. (This, in turn, facilitates a rapid context switch between hyperwebs located on the same site.) Finally, a limited form of inheritance exists between a web and its subwebs. In particular, any anchor or link available in a parent web is available in its children. This is not true object-oriented inheritance since a child web can not override the definition of an anchor or link defined in one of its ancestors. Rather it can only add new anchors or links to the existing set. Thus subwebs can be seen as adding context to a particular hyperweb, revealing new anchors and links over the same set of information when activated. In total, these new features provide the user with greater organization powers over the hypermedia structures they create with Chimera.

23 •

Hyperweb Server. The hyperweb server is responsible for implementing the manipulation and persistence of hyperwebs. In addition, it is responsible for managing the access to all hyperwebs located on its site. this latter responsibility includes preventing the operations of a Chimera client from over-writing the operations of another. This protection is implemented through the use of a simple locking mechanism. Clients lock instances of Chimera’s hypermedia concepts before modifying them and release the locks once finished. The hyperweb server is a potential bottleneck of the Chimera 2.0 architecture, since all access to hyperwebs is funneled through it. In order to mitigate against this bottleneck, each connection to the server is handled in a thread concurrently with other connections. The locking mechanism creates locks only on individual instances of hypermedia concepts, never at the level of an entire hyperweb. Thus if multiple clients access different parts of a hyperweb, they can all function in parallel without hindering each other. Finally, the hyperweb server addresses scalability issues by only loading into memory, hyperwebs which are being accessed by clients. If a loaded web is not accessed past a certain threshold, the hyperweb server saves it to disk and reclaims the memory it used.



Hyperweb Manager. The hyperweb manager is responsible for two primary duties. First, the user interface of the hyperweb manager enables the creation, deletion, and renaming of hyperwebs. Second, the hyperweb manager tracks the connection information for each server on its site. If an applet needs to contact a Chimera server on a particular site, it first requests the contact information from the site’s hyperweb manager. The hyperweb manager is easily located since it has a dedicated port number registered with the Internet

24 Assigned Numbers Authority (IANA). Thus in the same way accesses a site’s WWW server, accesses the site’s hyperweb manager. As implied by the latter URL, the hyperweb manager can accept HTTP requests directly. It implements a set of URLs which access its operations. In fact all Chimera 2.0 servers have this ability to expose their APIs via HTTP. In addition to reasons which will be discussed in Section 7.1.1, exposing a server’s API via HTTP provides an easy way for users to check on the status of a server from within a standard WWW browser.

1.3 Toolkit Integration Technique The toolkit integration technique (TI technique) [4] is a departure from the previous two systems in that it is not a stand-alone hypermedia system. Instead, it is an integration technique which relies on an underlying OHS to provide hypermedia services to the clients of a user-interface toolkit. Two prototypes have been constructed using this technique. These prototypes are discussed in Section 5.2.1. The conceptual architecture of the TI technique consists of the following elements: the client applications, the user-interface toolkit, the extended widgets, the hypermedia infrastructure, and the underlying open hypermedia system (See Figure 13). The design trade-offs explored in this technique include entry barrier vs. quality vs. applicability, and separation of concerns vs. all-in-one. Each architectural element and trade-off is discussed below.



Client Applications. Client applications make use of the integrated toolkit in order to take advantage of the provided hypermedia services. The difference between this integration technique and others is that the focus is not on client applications, per se, but

25

Integrated Toolkit

Applications

User-Interface Toolkit

Extended Widgets

Hypermedia Infrastructure

Open Hypermedia System

Figure 1-3. The Toolkit Integration Technique’s Conceptual Architecture Client applications make use of an integrated toolkit which consists of an original user-interface toolkit augmented by a set of extended widgets. These widgets offer the same user-interface services of their original counterparts but in addition provide basic hypermedia services such as anchor creation, link manipulation, and link traversal. Some extended widgets do not have counterparts in the original toolkit but instead provide access to specific hypermedia services such as search and query over the active hyperweb. These widgets communicate with the underlying OHS via the hypermedia infrastructure layer. This layer has three responsibilities: sending widget requests to the OHS, receiving and routing events from the OHS to the relevant widgets, and implementing common hypermedia services across widgets. This latter responsibility enables the widgets to behave consistently for similar services. For example, all OHS errors are handled by the hypermedia infrastructure allowing error handling code to be concentrated in one place. Another example is the handling of complex link traversals. If a link traversal has more than one or two destinations, the hypermedia infrastructure can display a dialog box which allows the user to specify the desired destinations.

rather on infrastructure which enables multiple client applications to be integrated. The advantage to integrating a toolkit is that all applications which use the toolkit behave similarly and users take advantage of that similarity to leverage their experience in one application in learning another. Thus, from the standpoint of the user, each application which uses the integrated toolkit provide similar hypermedia services across widgets and across applications.



User-Interface Toolkit. The user-interface toolkit provides client applications with userinterface services. Its widgets provide the basis for the extended widgets which the toolkit integration technique creates. As will be discussed in Section 5.2.1, certain architectural

26 features of a user-interface toolkit impact the quality of the final integration which can be achieved by the TI technique.



Extended Widgets. The toolkit integrator’s chief task is the construction of the extended widgets. These widgets extend the services of the original user-interface toolkit widget to include hypermedia services. This extension can be performed by completely reimplementing the widget or by the object-oriented method of inheritance. In either case, the extended widget gains access to the underlying OHS’s API via the hypermedia infrastructure. It must use the API to model its hypermedia needs and to invoke the appropriate operations in response to user input. For instance, a scrollbar might allow a user to create anchors along its vertical or horizontal track by shift-clicking in the appropriate spot. It must display these anchors in some manner and then allow them to be included in links via some other user input. In addition it must respond to hypermedia events such as link traversal. For instance, one response to link traversal might be to position the thumb of the scrollbar in the exact location of the anchor referenced by the traversal. In this manner, the view which is controlled by the scrollbar scrolls to some new location and the user would perceive the link traversal as having jumped to that particular portion of the view.



Hypermedia Infrastructure. The hypermedia infrastructure has two main responsibilities. The first is to provide access to the API of the underlying OHS. This enables the extended widgets to make calls on the OHS and receive events from the OHS. The second responsibility is to implement services common to all widgets. Examples of common

27 services include handling errors and complex link traversals and managing the connection to the underlying OHS.



Open Hypermedia System. The open hypermedia system implements the hypermedia services requested by the extended widgets. In this manner, the applications which contain the extended widgets become clients of the open hypermedia system. The advantage to this is that these toolkit-constructed applications can interoperate with any pre-existing OHS client. In addition, any specialized clients of the OHS such as link editors or map generators can also be used in conjunction with the toolkit-constructed applications.

1.3.1 Entry Barrier vs. Quality vs. Applicability A wide range of techniques exist for integrating clients with open hypermedia systems as shall be seen in the next Chapter. One trade-off made in these techniques is the tensions between the developmental barriers associated with the technique and the quality of the final integration and the applicability of the technique to a range of application types. For instance, some techniques take advantage of the characteristics of a particular operating system in order to integrate its applications without their awareness. This technique has a low-entry barrier for applications written for the target OS but without the application’s awareness the quality of the integration is typically low, and the technique is not applicable to applications running under other operating systems. Other techniques have high applicability and high quality but in turn are associated with non-trivial developmental effort. The TI technique lowers the developmental effort associated with the integration while producing medium to high quality

28 and wide applicability. The enabler for these characteristics is the nature of user-interface toolkits. First, a wide range of extended widgets produces an interface rich with hypermedia services, thus improving quality. Second, UI toolkits are used by a wide variety of applications, thus achieving wide applicability. Finally, most developers make use of a toolkit to produce some aspect of their application’s user-interface. Since the TI technique provides a default level of service automatically, developers simply have to use the extended widgets in place of their original counterparts to achieve integration. Thus, the entry barrier to the technique is low.

1.3.2 Separation of Concerns vs. All-In-One A key feature of the TI technique’s conceptual architecture is its separation of concerns with respect to user-interface functionality and hypermedia functionality. The UI toolkit provides the former while the OHS provides the latter. The remaining levels of the architecture, the extended widgets and the hypermedia infrastructure, are designed to minimize the impact of change in one of the outlying systems from the other parts of the architecture. Thus, a change to the hypermedia system may impact the hypermedia infrastructure but not the extended widgets. Or if it does impact the extended widgets, then the UI toolkit is protected from the change since it is left unaware of the integration in the first place! After the upgrade has been made, all client applications benefit from the result. This approach to the technique contrasts with systems which attempt to keep all services under their control. An example domain which uses this technique is groupware toolkits [17, 33, 58]. These toolkits provide groupware features while at the same time providing userinterface services to their client applications. However there is no separation of concerns

29 between the UI services and the groupware services. The groupware toolkit is the UI toolkit and vice-versa. The advantage to this alternative is that a deep integration between the two services is achieved. This leads to an increase in sophistication of the provided services. However the disadvantage is that the system is not as resistant to change. A change in the groupware services will most likely impact all client applications.

CHAPTER 2: Related Work

This dissertation covers work on three different sets of techniques. These techniques address the issues of supporting heterogeneity, integrating OHSs with the WWW, and providing hypermedia services via a toolkit. This chapter presents related work for each of these techniques. First, a section on open hypermedia systems is presented. Then, a taxonomy of OHS-WWW integration techniques is described. Finally, the related work within the domain of hypermedia-enabled toolkits is presented and compared to the toolkit integration technique.

2.1 Open Hypermedia Systems The field of open hypermedia systems has slowly emerged in the hypermedia literature over a period of ten years starting in 1987.1 In that year, a paper on the first hyperbase system “HAM: A general-purpose hypertext abstract machine” [11] appeared in the ACM conference on Hypertext. At that same conference, Meyrowitz gave a keynote speech (later published in [45]) entitled “The missing link: Why we are all doing hypertext wrong” which gave rise to research on the link server approach to hypermedia systems. In fact, the paper on Sun’s Link Service [54] appeared in the literature two years later. During this same time frame, a series of workshops held by hypermedia system developers defined the Dexter hypermedia model [30, 31] in an attempt to capture the best design aspects from all existing hypermedia systems. Dexter is considered in more detail below in the discussion of the Devise Hypermedia System (DHM). Finally, in 1991, Malcolm, et. al., [41] defined the requirements for “industrial 1. This history paraphrases some of the information presented in [75].

30

31 strength” hypermedia systems. They list the following characteristics required of hypermedia systems to support large scale industrial projects: interoperability, links and object attributes, link anchors, link types and functionality, private and public links, templates (link generators), navigational aids, configuration control, concurrency control, and programmability. They also call for direct support for hypermedia functionality in future operating systems, storage mechanisms, and computer networks.

Since then the open hypermedia system field has accumulated a large literature describing such systems as ABC [62], Chimera [2], DHM [23], Hyperform [70], HyperDisco [72], Microcosm [14, 32], Multicard [57], SEPIA [63], and SPx/HBx [35, 39, 50, 60, 61]. In addition a series of open hypermedia system workshops [71, 73, 74] have been organized to give this growing community a chance to interact and work together. With so many systems being developed and each using slightly different techniques and hypermedia models, Østerbye and Wiil developed a taxonomy for comparing open hypermedia systems [52]. Østerbye and Wiil excluded hyperbase systems from their taxonomy due to the content storage requirement these systems impose on their integrated applications. Instead, their taxonomy considers only link server systems and open hyperbase systems as open hypermedia systems. Open hyperbase systems typically provide a higher level of service to applications which store content within the hyperbase. However they no longer require applications to do so and offer link server functionality to applications which choose to store their content elsewhere. Finally, a definition of the term open as it applies to open hypermedia systems is included in the proposal for the Open Hypermedia Protocol [16]. The definition states:

32 “The term open implies the possibility of importing new objects into a system. A truly open hypermedia system should be open with regard to:

1. Size: It should be possible to import new nodes, links, anchors and other hypermedia objects of any limitation, to the size of the objects or to the maximum number of such objects that the system may contain, being imposed by the hypermedia system.

2. Data Formats: The system should allow the import and use of any data format, including temporal media.

3. Applications: The system should allow any application to access the link service in order to participate in the hypermedia functionality.

4. Data Models: The hypermedia system should not impose a single view of what constitutes a hypermedia data model, but should be configurable and extensible so that new hypermedia data models may be incorporated. It should thus be possible to interoperate with external hypermedia systems, and to exchange data with external systems.

5. Platforms: It should be possible to implement the system on multiple distributed platforms.

6. Users: The system must support multiple users, and allow each user to maintain their own private view of the objects in the system.”

33 Not all open hypermedia systems meet these requirements, but in addition to the industrial-strength requirements listed above, they provide a good basis for describing and comparing the features of open hypermedia systems. This section now considers a representative sample of open hypermedia systems and compares and contrasts them with Chimera.

2.1.1 ABC The open hypermedia system for artifact-based collaboration (ABC) [62] is an attempt to support the process by which individuals, groups, and organizations work together to build large artifacts of information. It consists of six key components: a graph server, a set of graph browsers, a set of data applications, a shared window conferencing facility, and realtime video and audio services.

The graph server provides access to a database of graph objects. This database is both scalable in the fact that it can be distributed across multiple hardware platforms and distributable in the fact that it consists of objects that tend to be accessed separately and have few dependencies on other objects. These properties provide for the collaborative access of the system by multiple users. The graph server distinguishes between structural links and hyperlinks. Each sub-graph of the database has an associated type like directed graph, acyclic graph, binary tree, or singly linked list. Structural links maintain the constraints for a given type. Hyperlinks can then be used to arbitrarily relate nodes within a sub-graph to each other or other sub-graphs.

34 Graph browsers are used to view the structure of the database managed by the graph server. New graph browsers are often created by reusing the code from a previously created graph browser and implementing new constraints for the different type of graph. Graph browsers often can display the data associated with a graph’s nodes directly. If not, a data application is used. Typically, these data applications are third party applications integrated into the system using the ABC System Matrix [62].

The System Matrix provides an environment in which unmodified, unaware third party tools can be integrated into the ABC environment with the System Matrix providing conferencing and hypermedia functionality. This integration is accomplished in the following manner. The System Matrix provides a window which mimics the user’s normal desktop environment. Any tool invoked in the System Matrix window has its main window “reparented” so that a row of ABC-related menus (providing hypertext and conferencing functionality) appears along the top of the application’s window. This type of integration allows for document to document links in that the unaware application can only be made to open a certain data file not display or create anchors within the document. In order for that to occur, the application must be modified to communicate information about a selection to the System Matrix. The information needed by the System Matrix and the protocol for communicating to it has been standardized so that the required changes to an application are minimal and well-understood.

ABC’s design made several different choices from those found in Chimera’s design. The key difference is the use of a hyperbase, a.k.a the graph server, to store the content of the

35 hypermedia system’s clients. Chimera does not make use of a hyperbase since it limits support for the heterogeneity of data formats. As noted above, straight hyperbase systems are not considered open hypermedia systems by Østerbye and Wiil, however ABC’s System Matrix blurs the lines with its support for unaware third-party applications. Essentially, the System Matrix takes advantage of a homogenous feature of its environment to provide powerful support for collaboration and hypermedia. In particular, the System Matrix exploits the fact that all of ABC’s clients make use of the X windows user-interface architecture. By invoking an application within the System Matrix and detecting for common initialization calls (such as creating the base frame of an application’s user-interface), the System Matrix can take over an application’s user-interface and provide ABC user-interface features. Since the System Matrix is intercepting all user-interface related operations made by its clients it can provide synchronous groupware capabilities by replicating the operations across multiple instances of the System Matrix.

Chimera, in contrast, takes a minimal approach specifying dominion over a comparatively small set of features and requirements with respect to its clients. It further modularizes most of these requirements by encapsulating them within the Chimera API. Thus, while Chimera cannot provide the same set of features that ABC provides for its environment, its support for heterogeneity is greater than that of the ABC system and in particular doesn’t depend on features of the host operating system. This, in turn, allows Chimera’s techniques to be applied in different operating environments. In contrast, there is no guarantee that the techniques used by the System Matrix are applicable on other computing platforms.

36 2.1.2 DHM The Devise Hypermedia system [23] is an open hyperbase system based on the Dexter hypermedia model [31]. DHM has extended the Dexter model to include support for dangling links [26], composites [25], dynamic links and embedded references [27]. In this section, we briefly describe the Dexter model and compare it to Chimera’s hypermedia model before describing the DHM system in more detail.

Dexter defines three layers: the run-time layer, the storage layer, and the withincomponent layer. The storage layer sits in the middle and interfaces with the run-time layer via presentation specifications, and the within-component layer via anchors. The storage layer creates a network of components of three types: atomic, composite, and link. Atomic components contain data stored in the within-component layer and presented by tools in the run-time layer. In addition, atomic components contain anchors which index directly into the data and allow the data to be linked. Composite components allow scalable hyperwebs to be constructed. Link components contain specifiers which describe how atomic and composite components are linked together.

Chimera’s hypermedia model is similar to Dexter in that its notion of a client parallels Dexter’s run-time layer. Chimera more clearly defines the run-time layer as consisting of distinct groups of clients each group servicing a different user. In addition, Chimera specified that each client contains one or more viewers of various data types. These definitions accurately model the server’s run-time environment and enable the rapid and accurate routing of hypermedia events.

37 Chimera has no parallel to Dexter’s presentation specifications. These specifications were designed to specify simple properties of an anchor such as “This anchor should appear as underlined text with a red foreground color in 14 point courier font.” Chimera’s view concept abstracts away all presentation details including the appearance of data, anchors, and the notification of hypermedia events. Instead these details are left to the viewer to tailor to suit its user-interface. Another difference is that links in the storage-level contain anchors which are direct indexes into data stored in the within-component layer. Chimera attempts to avoid this direct indexing by associating anchors with views, thus enforcing a separation between objects and anchors. This separation encourages viewers to leave hypermedia information out of their native data types and instead use attributes stored on anchors to maintain the association of a conceptual anchor to a specific region within a view of an object. Even Chimera 2.0’s support for view-independent anchors associate these anchors with object place holders in the hyperweb server and not with the objects themselves.

With respect to the extensions to Dexter made by DHM, Chimera 2.0 adds support for composites (any object can have a set of sub-objects associated with it; views can then be based on any of the sub-objects or the composite itself ) and dynamic links (viewers can supply dynamically-loaded behaviors to the Chimera server which implement new link traversal semantics including the computation of link destinations). Chimera’s hypermedia model has always supported dangling links since it models links as sets of anchors and embedded references (such as HREFs located in HTML) can be modeled by storing the URL of the reference as an attribute on a Chimera anchor. In fact, Chimera’s integration with Mosaic utilizes this exact technique to map Chimera anchors into WWW URLs.

38 DHM [26] is an open hyperbase system based on (an extended version of ) Dexter. DHM is implemented as a three-tier client-server system corresponding roughly to the three layers of the Dexter model. An object-oriented database (OODB) fulfills the responsibilities of Dexter’s storage-layer storing both hypermedia structures and application content. The OODB, developed in parallel with DHM, provides flexible locking, transaction, and event notification services. These services are used to implement a wide range of support for cooperative hypermedia-related work [24]. The OODB represents a primary difference between DHM and the Hyperform project discussed below. Hyperform makes use of a hyperbase which is a database tailored to support hypermedia. The OODB in contrast is a general purpose object-oriented database which provides its services over all objects regardless of whether they relate to hypermedia structures or application-specific information. In contrast, a hyperbase’s services are tied to particular classes and thus providing the same service to a new class requires more work than with the OODB mechanism. The run-time layer sits on top of the OODB and is populated with runtime processes (RPs), one process for each user. RPs maintain a connection to the OODB and act as a conduit for the requests of a user’s applications which execute within the within-component layer. An RP is thus similar to Hyperform and HyperDisco’s tool integrator discussed below. DHM is implemented in a highly portable programming language and has been deployed on a variety of hardware and operating system platforms including various flavors of Unix, MacOS, and Microsoft Windows. Recently, DHM has been extended to integrate with the World-Wide-Web (discussed below).

39 Chimera does not have the same sort of explicit separation of the three Dexter layers as found in DHM. Chimera’s hyperwebs make up the storage layer but these entities are separate databases managed by the Chimera server. In addition, Chimera is not a hyperbase system and does not provide services to store application content. The Chimera server and the Chimera API split the responsibilities of the RPs between them. The Chimera API allows clients to communicate with the Chimera server while the Chimera server implements internally a data structure which tracks which clients are associated with which users. The Chimera server implements a well-articulated event notification system but can not match DHM’s support for cooperative hypermedia due to its lack of support for locking and transactions. This lack of support and plans to correct it are discussed in more detail in the HyperDisco section below.

2.1.3 Hyperform Hyperform [70] is an open hypermedia system based on the notion of extensibility. Its server provides an object-oriented extension language (Elk) which is interpreted at run-time to allow the dynamic modification to the server’s hypermedia data model or addition of new operations on existing data model objects. The server also provides a small class hierarchy providing basic services such as concurrency control, notification control, access control, version control, and search and query. These classes can be sub-classed using multiple inheritance to support various hyperbase configurations. Hyperform’s database has no restrictions on the number of classes or objects which are active at any one time. This enables Hyperform to execute multiple hypermedia models concurrently. Several previous hyperbase

40 systems such as HAM [11] and the Danish Hyperbase [69] have been successfully simulated by Hyperform as a demonstration of its extension capabilities.

Chimera 1.0 does not provide support for the extensibility of its hypermedia model. Chimera’s hypermedia model, as defined by its set of hypermedia concepts, was developed by examining the requirements placed on a hypermedia model by typical applications found in software engineering environments. The notions of viewers, objects, and views are sufficiently general to capture the needs of a large range of client applications. Thus Chimera’s research focused more on providing an API which completely opens the manipulation of elements of the hypermedia model to client applications. This, in turn, reduced the need for extensibility. Chimera 2.0 adds support for extensibility in link traversal semantics. Clients can now encapsulate link semantics in Java objects which can be transmitted to the server for execution. This capability combined with the modifications of the hypermedia model discussed in Chapter 4 further reduces the need for extensibility since the model is able to more accurately reflect the hypermedia needs of client applications.

On the client side of Hyperform, the tool integrator is a flexible extensible interface to the Hyperform server. It can integrate external tools through the use of a socket based interface or it can dynamically load internal tools written in Elk. The major advantage to using the tool integrator is that it can perform caching of server data structures to decrease network traffic and increase application response time to hypertext events. It is comparable to Chimera’s API in that applications gain access to hypermedia services through it use but the tool integrator embodies more functionality than presented in the Chimera API. It is more

41 akin to a Chimera wrapper which integrates a tool by interpreting the protocol of the application and mapping the events which occur within that protocol to operations on the API.

2.1.4 HyperDisco HyperDisco [72] is an open hyperbase system developed using the Hyperform hypermedia system development environment [70] discussed in the previous section. HyperDisco has as its goal the ability to provide high level support for seven characteristics of open hypermedia systems: scalability, openness, distribution, heterogeneity, interoperability, extensibility, and computation. It expands on Hyperform’s architecture of a hyperbase and tool integrator by generalizing these into two separate layers, an integration layer and a data layer. The integration layer consists of one or more tool integrators coordinating the access of tools to one or more hyperbases in the data layer. The integration layer provides anchor and link classes which can be extended (at run-time if need be) to achieve an integration with a client application. The extensible run-time system in hyperform is used to allow a single tool integrator to integrate multiple tools at once each with their own extensions to the anchor and link classes. The data layer provides classes for components, nodes, composites, links, and anchors. A component (which is the superclass of nodes, composites, and links) inherits functionality from parent classes which provide concurrency control, notification control, version control, access control, and query & search for instances within a hyperbase. These classes enable advanced services such as versioning and collaboration for fully-integrated or partially-integrated applications.

42 As the previous sentence implies, HyperDisco can integrate applications at various levels of functionality. Clients can be integrated unawares into the system which allows them to be the destination of link traversals (this requires an intermediary to register their documents and include those documents into links, but after this configuration has been established, HyperDisco will automatically invoke the unaware client whenever it is needed.) Unaware clients can not instigate link traversals nor can they provide any hypermedia services. Partially-aware applications typically store their anchors and links in the hyperbase and their content in the file system. HyperDisco can still provide versioning and collaboration services for partially-aware applications as long as two conditions are met. First, the tool integrator must register data wrapper objects within the hyperbase which act as placeholders for each file of the partially-aware application. Second, all tools which access the file must notify a tool integrator of their actions so that the hyperbase can properly track the state of the file. This leaves HyperDisco vulnerable to the unaware edit problem in which a hypermedia-unaware application can edit a file within the hypermedia system’s domain without notifying the hypermedia system. All open hypermedia systems are vulnerable to this problem, however. A typical solution is to implement services which detect when files have been edited by hypermedia-unaware tools and instigate processes for verifying the integrity of the hypermedia structures associated with the file [32]. Fully-integrated applications store anchors, links, and content within HyperDisco’s data layer and implement event handlers to respond to HyperDisco notifications. The tool integrator provides default event handlers for certain events when integrating a partially-aware application.

43 HyperDisco has been used to perform a partial-integration of a set of tools (emacs, LaTex, xdvi, dvips, and PageView) to demonstrate its collaborative and versioning facilities. As discussed below, it has also extended its support for distribution in the data layer by enabling a user to connect to hyperbases which are located at a remote site. HyperDisco has demonstrated the power and flexibility provided by the open hyperbase approach. The hyperbase enables versioning and collaboration with its ability to provide locking, access control, and notifications services over the objects stored within it. The ability of the tool integrator to register data wrapper objects for partially-integrated tools further increases the range of applications for which these advanced services can be provided.

Chimera is clearly behind HyperDisco in its support for versioning and collaboration. This is a result of the separation of concerns design approach which underlies Chimera’s implementation. Chimera was intended to only provide link server-style services and rely on other systems to provide functionality like versioning. Chimera’s support for collaboration has always been hobbled by its lack of support for locking concepts within a hyperweb, i.e., Chimera’s event notification service is able to keep multiple-users informed of each others actions within a shared hyperweb but without support for locking it relies on users to coordinate their modifications via some other communication channel.

Chimera 2.0 is beginning to address these problems. A simple locking mechanism over hypermedia concepts has been implemented and support for transactions and versioning of hypermedia concepts will be added in a future version of the hyperweb server. Since Chimera does not employ the hyperbase approach, cooperation with external configuration

44 management systems will be required to support the versioning of application content. Future work will address this need by developing protocols which will enable this type of cooperation to occur.

2.1.5 Microcosm Microcosm [14] is an open hypermedia system consisting of four distinct parts: a set of viewers, a set of filters, a document control system, and a filter management system.The document control system handles hypertext events from the set of viewers and routes them to the filter management system. The filter management system sends these events (represented by tagged ASCII strings) to the set of filters for processing. Each filter is allowed to scan the incoming message for tags that it recognizes (i.e. source anchors), perhaps perform some computation in response (i.e. compute the destinations), and insert tagged output (i.e. destination anchors) into the message before passing it on to the next filter. At the end of its journey through the set of active filters, the filter management system scans the message for any resulting actions and directs the document control system to perform those actions by directing the viewers to respond (i.e. display the destination anchor(s) to the user). Filters can perform many different functions and can be effortlessly swapped in and out by the user to modify the system dynamically. Microcosm has been recently extended such that the filters and viewers can be distributed across a network [12].

Microcosm has three levels of integration with its viewers: fully-aware, partially-aware, and unaware. Fully-aware viewers have been developed to exploit the full functionality of Microcosm. These viewers can display anchors on objects it displays and can respond to

45 events which tell it to display a particular anchor. Partially-aware viewers are typically thirdparty viewers which contain a sophisticated macro package. Using the macro facility, these viewers can be modified to send messages to Microcosm in the appropriate format, and respond to incoming messages to open particular files. These viewers are often not able to handle commands to display a particular portion of a file since they were not built with hypertext in mind and thus contain no notion of anchor upon which to link.Unaware viewers are those which can be invoked on a particular file but offer no other mechanism with which to extend them. Microcosm has been able to integrate these viewers with two techniques. The original technique was for the user to make a selection within the application and copy it into the clipboard provided by the host operating system for cut-and-paste operations. The user then switches to the Microcosm application and performs hypertext actions upon the contents contained in the clipboard. This technique has been replaced by the second technique [15] which is referred to as the universal viewer. Reminiscent of the ABC System Matrix, the universal viewer attaches itself to the unaware viewer and adds a menu (and iconic buttons) along the top of its window to provide the user with an interface to access Microcosm functionality.

2.1.6 Multicard Multicard [57] is an open hypermedia system built around an advanced scripting language, a communications protocol (M2000) and a C++ hypermedia toolkit which allows programmers to build and manipulate hypermedia structures. Its hypertext structures include nodes, groups, anchors, and links. A node is the basic unit of information in a Multicard network. Groups are used to relate nodes and other groups. Anchors refer to a specific

46 location within a node’s content. Multicard handles the storage and management of Multicard scripts associated with nodes, groups, and anchors; M2000 compliant editors manage the contents of the nodes and the mapping of an anchor to a portion of the node’s content. Links are treated as a communication channel between two anchors. This communication channel is then used to pass scripts and events back and forth between the two end-points. This enables flexible dynamic behaviors between two linked applications and has proven useful in prototyping applications that are evolving rapidly.

Multicard’s scripting language is event-based and contains over 150 commands that bring the functionality of the hypermedia toolkit to the end-user. This allows the end-user to tailor the behavior of M2000 compliant editors on the fly. The M2000 protocol, which defines the messages that can be sent to and received from the Multicard server, is used to integrate third party tools into Multicard. Multicard has been used to develop several real world applications.

2.1.7 SBx/HBx The Hypermedia Research Laboratory (HRL) at Texas A&M University has engaged in the building of several hypermedia systems (SP 0-3) since 1991 [35, 39, 61]. At the same time, the HRL has also built a series of hyperbase systems (HB 0-3) to support the data storage requirements of these hypermedia systems [60]. SP3 defines a simple hypertext model. Applications manage components which have persistent selections created upon them. These persistent selections are attached to anchors which are then associated with links. These links create association sets that are modeled in the underlying hyperbase.

47 This matches Chimera's hypertext concepts fairly well. The only difference being that multiple persistent selections can be associated with a single anchor. In Chimera, if the viewer wanted to associate multiple regions of its view to one anchor it could do so, but this would necessarily make the mapping function between anchors and regions of the view more complex. Typically Chimera viewers map one region per anchor, which would be the equivalent of mapping one persistent selection to anchor in SP3. A distinctive feature of the HRL work is that anchors and links are first-class executing programs that can provide a wide range of run-time semantics. It also allows user interaction with hypertext services to be handled by the anchor and link processes taking this burden off of the client applications. (This is handled by virtue of the fact that anchors and links are supplied as classes which have a default set of behaviors which applications can subclass and modify as desired.) SP3 and HB3 provide a sophisticated environment that represents a first attempt at providing hypermedia-in-the- large.

The differences between Chimera and the HRL work are many. For instance, Chimera is not yet at a state where it can support multi-user collaboration on a shared hyperweb. A few additional differences are outlined below.



Chimera has taken a different approach with respect to anchors and links. They are objects managed by viewers and the Chimera server respectively as opposed to being firstclass processes. This allows for anchors to be specifically tailored to a viewer while placing a burden on viewer developers to implement this functionality for each new viewer. It

48 allows links to be handled in a consistent manner at the price of implementing special link behaviors in the Chimera server.



SP3 requires applications to use its object manager (HB3) to store application data; this allows SP3 to support versioning of application data and hypertext information. Chimera, in contrast, places no such restrictions on its viewers requiring viewer cooperation to provide reliable versioning.



Chimera associates anchors with views, while SP3 associates anchors with persistent selections which refer directly to an application's data. This enables Chimera, when combined with a viewer mechanism such as Chiron [66], to provide greater flexibility in displaying an anchor, supporting the ability of several viewers (concurrently) providing different views of the same object, where the anchors and their presentation are viewspecific (and this all separated by Chiron from any application code). This is similar, though, to SP3's notion of a context. In SP3, depending on the context, different sets of anchors and links will be made available to an application displaying the object. Contexts are handled in Chimera through a combined use of attribute-value pairs and the filtering of anchors and links by the Chimera server for a particular view.



SP3 links are not “ordinary” objects and thus anchors cannot be defined upon them and thereby participate in hierarchical webs. Thus Chimera appears to have a scalability advantage.

49

2.2 OHS-WWW Integration There are many ways available to integrate open hypermedia systems with the World Wide Web. A simple taxonomy of possible integrations between OHSs and the Web is developed to provide context for a discussion of these techniques. The taxonomy is constructed by considering the intersections between the four major architectural elements common to both systems: clients, servers, protocols, and data formats. All possible intersections will not be considered, instead only areas in which work has occurred are discussed. Hybrid integrations drawing on more than one intersection are also discussed.

2.2.1 OHS Data to WWW Data One simple integration is to produce tools which translate links and content within an OHS into HTML. While most likely there will be restrictions on the type of information and functionality that can be translated, this integration has the important property of leaving the elements of both systems unmodified. This eases the amount of work required to achieve the integration. The only effort, then, is the development of the translators which is significantly less effort than modifying the server of an OHS or extending a WWW server. This type of integration allows an end-user to enjoy the benefits of creating content within an OHS while at the same time retaining the ability to then publish the information on the Web.

The Microcosm group [32] has done work in this area by producing a tool which converts Microcosm applications into a set of linked HTML documents. This conversion has a number of restrictions: only RTF documents and BMP images can be translated by the tool into HTML and GIF respectively. In terms of hypermedia functionality, the tool can easily

50 convert Microcosm specific links and buttons into HTML links. Local and generic links can be converted as well, however this involves searching the text of every document included in the application to find all possible destinations. [32] also points out the difficulty of translating links with multiple destinations into HTML and discusses several strategies to deal with this problem.

2.2.2 WWW Client as OHS Client Another simple integration is one in which a WWW client (i.e. a Web browser) is integrated with an OHS. Such an integration is reported in [32] for Microcosm and in [2] for Chimera. The former integration was performed using Microcosm’s Universal Viewer and the latter was performed using a Chimera wrapper. This type of integration achieves a level of functionality such that HTML pages can be linked “out of the Web” and into the other clients supported by the OHS. This has the advantage, for instance, of allowing developers to write their documentation in HTML and then link it directly to the relevant application.

A more advanced version of this type of integration is illustrated in the work to integrate DHM with the WWW [28]. That paper discusses three approaches to integrating WWW clients with DHM using mechanisms such as applets, JavaScript, and browser plugins. It concludes that the technology is not yet sufficient for a platform/browser-independent solution. However the integrations achieved do show promise for the technique of combining several Web mechanisms in tandem to achieve a strong integration.

51 Chimera 2.0 has performed work in this area with its ability to support Java applets as full Chimera clients. This allows applets to provide hypermedia services over the objects within their domain as well as provide access to Chimera 2.0 services from within any Javaenabled Web browser. Chapter 4 discusses this work in more detail.

The effort to perform this type of integration is low when targeting a specific browser or platform. Microcosm’s Universal Viewer makes the process trivial under Microsoft Windows, and creating a Chimera wrapper for an application with an external application program interface (API) is not difficult. The disadvantage to this approach is that current Web mechanisms are not set up to help outside systems override the default hypermedia model of the WWW. Instead these mechanisms are tuned to help display new media types within a browser or to implement simple client-server applications. The feedback gained from the difficulties encountered by work such as the DHM effort should help the Web community respond with improved mechanisms to achieve more universal integrations.

2.2.3 WWW Server as OHS Client A deeper integration can occur by extending a WWW Server to be a client of an OHS. In this approach, users gain the ability to access the functionality of the OHS from a standard unmodified Web browser. The Web server is modified to make calls on the OHS in response to requests for certain URLs. Based on the response to these requests, the server generates HTML to be sent back to the client which presumably contains markup that manifests the presence of the OHS.

52 This approach has the principle benefit of separating links from Web documents, since the links are generated and inserted dynamically. In addition, authors can continue to create hyperwebs in their favorite OHS and have the results transparently available via the Web.

Implementation mechanisms for this integration include extending the WWW server directly via changes to its source code, using a server plug-in, or implementing a CGI script. The first two options provide performance benefits, while the third is stronger with respect to portability between Web servers. One other implementation mechanism for this approach is to use a client-side HTTP proxy. This mechanism has the advantage of allowing the user to specify when they wish to access the OHS’s services, and the additional benefit that the work required to modify the Web server is avoided. The disadvantage of this approach is that the developers of the proxy must deal with cross-platform portability issues.

The Microcosm group has performed work in this area in a project called the Distributed Link Service (DLS) [12]. In this system, Web servers have been extended to access distributed linkbases and filters. In response to client requests, information in the linkbases is “compiled” into the HTML document as URLs on the fly.

The work integrating DHM with the WWW [28] also falls under this category. The client integrations mentioned in Section 2.2.2 access URLs which invoke cgi-scripts which in turn access the DHM server for external anchor and link information.

53 Finally, Chimera 1.0 explored work in this area by modifying a WWW server to map URL requests into Chimera API operations [5]. For instance, a URL of the form

would cause the modified WWW server to invoke the

Get_Viewers operation of the Chimera API. The server would take the results of each call and dynamically generate HTML which displayed the requested information and contained embedded URLs which retrieved related information. For instance, a document displaying information about a link would contain URLs which would retrieve information about the anchors included in the link. This technique demonstrates a rapid low-cost way of developing a browser for the hypermedia structures contained within an open hypermedia system.

2.2.4 Hybrid Integrations Hybrid integrations apply two or more of the techniques described in this taxonomy and apply them simultaneously in one hypermedia application. A popular hybrid integration is to combine the strategies of Section 2.2.2 and Section 2.2.3. The result is a powerful hypermedia environment for the end-user. In addition to using normal OHS clients, they can now effortlessly link in and out of Web documents. In addition, due to the server integration, anchors and links created on Web documents are stored externally in the OHS’s hypermedia database yet appear as standard Web links when rendered by a Web browser. A user also has the power to configure and access other services of the OHS from within the Web browser due to the client integration.

The DHM work [28], described previously, is an example of this type of hybrid. In addition, DLS [12] achieves this hybrid integration via a modification to the Microcosm

54 Universal Viewer which allows users to access standard Microcosm features through the integrated Web server described in Section 2.2.3. Chimera 2.0 represents a hybrid of a different kind [5]. This is discussed in more detail in Section 4.

2.2.5 OHS Server as WWW Server One interesting form of integration is to modify an OHS server to masquerade as a WWW server. While the results of this integration from the standpoint of an end-user is similar to the previous section, it offers greater flexibility to the OHS. Performance is improved since the OHS receives HTTP requests directly and has immediate access to both the requested document and its hypermedia database. Additional services can be made available since more of the OHS’s API can be exposed to WWW clients. However this integration entails significant developmental complexity since implementing the functionality of a Web server is not trivial. This complexity can be mitigated by limiting the scope of URLs handled by the OHS server. Chimera 2.0 implements just this technique with its server’s support for HTTP (discussed in more detail in Section 4).

The most notable work in this area has been performed by the Graz University of Technology, Austria, through its Hyper-G project [42]. This system is an advanced hypermedia authoring environment which integrates with the Web by having its server masquerade as a WWW server. Normally Hyper-G information is best viewed with a proprietary client called Harmony, however Hyper-G servers have the ability to receive requests from standard Web clients and translate their information (with an associated loss of

55 functionality) into HTML. Users can thus gain access to the large amount of structural information stored in Hyper-G from any standard WWW client.

2.2.6 WWW Protocols Within an OHS This approach to integration employs WWW protocols within an OHS to help leverage their distribution and standardization benefits. For instance, the hierarchical structure employed by WWW servers to organize information within websites can be used to organize the management of hyperwebs within an OHS. In addition, the use of URLs to locate OHS components allows for these components to be globally distributed, yet accessible in a way familiar to all Web users.

HyperDisco [72] has demonstrated the ability to access workspaces distributed across the Internet [75]. These workspaces contain hypermedia information as well as content. The HyperDisco tool integrator has been extended with a workspace class which enables it to communicate and manipulate with any workspace regardless of its location. Web protocols were not utilized to enable tool integrators to discover remote workspaces, however. Instead, a name service is used which places a small amount of work on the user in terms of maintenance (users must manually enter connection information for remote workspaces) but offers more transparency and flexibility than the URL protocol (the user can assign names to workspaces, and allow the name service to map these names to the proper workspace).

Chimera 2.0 performs similar work with its support for distributed hyperwebs [5]. Unlike the HyperDisco work, it makes use of Web protocols to reference and establish access

56 to these remote hyperwebs. In addition, these hyperwebs are link server databases and not full hyperbases like HyperDisco’s workspaces. Thus, Chimera 2.0 hyperwebs contain only hypermedia structures and no application content. Chimera 2.0’s support for Web protocols is discussed in more detail in Section 4.

2.3 Hypermedia Infrastructure The TI Technique [4] leverages the research and experience in several domains to achieve its integration. Aspects of the technique are thus related to a wide body of work. In this section, we consider several areas of related research including hypermedia toolkits, open hypermedia systems, groupware toolkits, and alternative integration techniques.

2.3.1 Hypermedia Toolkits Hypermedia toolkits provide applications with hypermedia abstractions and services in much the same way user-interface toolkits provide user-interface services. Typically, applications make use of these toolkits by extending the hypermedia classes provided. This allows an application to specialize the classes for its domain while taking advantage of the hypermedia services provided. HOT [55] provides a set of C++ data and view classes and is useful for constructing closed hypermedia-enabled applications. Garrido and Rossi [22] provide similar services to SmallTalk applications. This hypermedia framework, however, provides specialized graphical widgets which can be used to provide link markers and navigational services. These widgets depend on the application using the rest of the hypermedia framework in order to function properly.

57 The primary difference between these toolkits and the TI technique is one of focus. The former provides classes used to gain hypermedia functionality; the latter provides graphical widgets which provide hypermedia services automatically. In the former, the impact on an existing application is greater since the application must be modified to explicitly use the provided classes. In the latter, the application simply swaps non-integrated widgets with integrated ones. Not all widgets have to be swapped either, since integrated and nonintegrated widgets can coexist freely in the same interface. The effort associated with the swap is minimal, at most the developer has to provide the context information required by the integrated widgets’ constructors and implement a callback routine to respond to link traversal events which require the display of a different object. Finally, the latter makes use of an OHS, allowing toolkit-constructed applications to interact with any other OHS client, whereas the former can only create closed hypermedia applications.

2.3.2 Open Hypermedia Systems DHM [26], Hyperform [70], and HyperDisco [72] all provide hypermedia frameworks which make use of an underlying OHS. These toolkits share the differences the ones above have with the TI technique except for the last; since these frameworks access an underlying OHS, the integrated applications can interoperate with any other OHS client. However, the TI technique shields the interaction with the OHS from the application developer since this interaction occurs within the integrated widgets. Thus the effort associated with using the technique is still lower than with these frameworks and the services provided by the technique match the navigational capabilities of partially-integrated OHS clients [72].

58 The TI technique however cannot match the high-end features provided to both partially- and fully-integrated OHS clients since these frameworks are capable of providing sophisticated features like versioning and collaboration [72]. Support for such features can be provided in one of two ways. If the underlying OHS provides these features, the toolkit integrator can use them within the integrated widgets. Otherwise, the TI technique could possibly be used to integrate a different type of system which provides the desired features. The application would then make use of the widgets which accessed both the OHS and the new system. This approach and its associated problems are discussed in Section 7.2.3.

2.3.3 Groupware Toolkits The CSCW field has conducted research into the requirements of groupware, and has produced toolkits to aid in the construction of groupware systems. Three notable examples are GroupKit [58], Rendezvous [33], and Suite [17]. These toolkits are relevant to the TI technique in the way in which they integrate user-interface and groupware services. There are several major differences. First, these systems do not use a separate service to provide groupware features; instead, the toolkit is the groupware system. Second, the focus of these systems is not on enabling widgets with groupware services. Rather it is on sharing entire applications between participants of a collaborative session, including not just an application’s user-interface but application state as well. Finally, as a result of the previous difference, these toolkits place significant architectural requirements on client applications in order to take advantage of their services. This encourages the development of new applications built in the toolkit’s style but makes it more difficult to adapt existing applications.

59 2.3.4 Alternative Integration Techniques Additional work has been performed in the area of integrating hypermedia services into applications. One simple but powerful example is reported in [18]. A text widget was modified to access the hypermedia services of an OHS. As a result, any application which made use of the new widget gained hypermedia functionality. The TI technique provides this type of integration to all toolkit widgets, however at a potentially lower level of service. The difference is that the source code of the text widget was directly modified to achieve the integration. The TI technique attempts to provide its services without modifying the original widget. Thus the level of service provided may not be the same as achieved with a custom integration.

Kacmar provides a different integration technique in Freckles [36]. Freckles integrates the windowing system of a user’s environment with an OHS. The title of an application’s window is used as the context to associate hypermedia structures with an application. Link markers appear as small rectangles (actually separate windows) which are associated with particular windows. Mouse clicks on these markers invoke hypermedia operations. Additional operations are accessible in a menu provided by the hypermedia system in a separate window. Since all link markers appear and behave the same, this technique provides consistent crossapplication hypermedia services similar to the TI technique.

This technique requires less effort to integrate an application than the TI technique. The only modification required is for the application to respond to a link traversal. The TI technique further requires the application make use of the integrated widgets. This additional

60 requirement, however, provides a deeper integration than the Freckles technique. Freckles provides an environment to rapidly prototype and evaluate hypermedia functionality within an application. The visual look and feel provided by the link markers, however, cannot be easily incorporated into the application as a functional component. In the TI technique, the integrated widgets are the link markers and already exist as a functional part of the application. Thus, in this context, the TI technique can be seen as a way for developers to ease the developmental process of incorporating hypermedia functionality, once they have determined from the prototypes that it is appropriate for their applications.

The TI technique illustrates an important concept. If infrastructure such as a userinterface toolkit is made hypermedia-aware then all applications which make use of the infrastructure become hypermedia-aware. Instead of integrating one application at a time, this technique integrates whole classes of applications at a time. Integrating infrastructure is a way to address the large-scale provision of hypermedia services. As other types of infrastructure are integrated, hypermedia services become more and more pervasive. However, underlying all infrastructure services is the operating system itself. A bottom-up approach to this technique would be to move hypermedia services into the operating system. Researchers at Texas A&M University have been exploring this issue within the context of the HOSS project [50].

HOSS is a follow-on project to the SP3/HB3 project described above and extends its architecture and ideas down into the operating system. The HOSS project defines a general architecture for a hypermedia operating system. The architecture consists of four main elements. On top sit applications and command interpreters making use of the services below.

61 At the bottom is a set of traditional operating system processes to manage memory, processes, I/O, and networking. These traditional processes however would be augmented to take advantage of information provided by the other two elements which sit between the former two. The first element has the duties of a traditional hyperbase. It manages access and provides storage for versioned objects (application content and the like) and structure (hypermedia relationships). This hyperbase layer sits above the OS layer and below the second hypermediarelated element, the link server layer. The link server layer provides a cache mechanism for structure information and a set of behaviors which can be dynamically loaded and executed concurrently. Each behavior shares information stored in the structure cache and can be used to perform queries, link traversals, and other hypermedia operations.

The research reported in [50] is still at an early stage of development and the issues being focused on deal more with efficient algorithms for caching structure and implementing fast communication mechanisms between the link server and hyperbase layers. In fact, the issue of application integration is mentioned but not explored in depth. As such, the TI technique currently highlights application issues more clearly than the HOSS work. In fact, issues such as the default level of hypermedia service to provide, and the communication mechanisms between application and infrastructure will still be valid regardless if the integrated toolkit sits on top of a hypermedia operating system or an open hypermedia system.

CHAPTER 3: Support for Heterogeneity

The diversity of modern computing environments makes the support for heterogeneity in an open hypermedia system essential. Typical environments contain hundreds of applications, thousands of information types, multiple storage mediums, and various network topologies. The relationships between these elements are often implicit and must be memorized or in some way tracked by the end-user. Hypermedia, as discussed in the Introduction, is one approach to managing this heterogeneity. In general the less restrictions an open hypermedia system imposes on its clients the greater its ability to service a wide range of applications. This, in turn, increases the number of data types an OHS can link together. A number of dimensions exist which influence an OHS’s support for heterogeneity. This set includes programming language support, operating system support, conceptual abstractions employed, link semantics support, client architecture assumed, and the system’s entry barrier to use.



Programming Language Support. Can the OHS support clients written in multiple programming languages? Are clients expected to be written in only one language?



Operating System Support. How many operating systems are supported by the OHS? Since most OHS’s implement a TCP-based inter-process communication protocol, this dimension also considers what operating system is required to run the OHS’s server.

62

63 •

Conceptual Abstractions. This dimension refers to an OHS’s hypermedia data model and other abstractions which enable hypermedia services within client applications. In particular, what features of these abstractions support heterogeneity?



Link Semantics Support. Is the notion of link traversal pre-defined by the OHS? Or can the user or client developer specify new behaviors for link traversals? If so, what mechanisms are employed to support the specification of link semantics and are they static or dynamic (or both)?



Client Architecture. Does the OHS assume a particular client architecture for its clients? This issue is related to the second issues above, since an operating system can influence certain aspects of a client’s architecture. In addition, this dimension also considers the responsibilities of a client with respect to the OHS.



Entry Barrier to Use. As an OHS’s support for heterogeneity increases, its entry barrier to use decreases. That is, the less restrictions imposed by the OHS on its clients, the easier it is to include support for the OHS within the client. This dimension is influenced in part by the other issues listed above but it also considers any restrictions imposed by the OHS which influences the work associated with client integration.

The Chimera open hypermedia system [2] is a vehicle for exploring the application of multiple techniques in tandem to achieve a high degree of support for heterogeneity. In particular, Chimera provides a flexible set of hypermedia concepts, a distinct separation of

64 clients and viewers, a small set of client responsibilities, dynamic link semantics, multiplatform support, and an API provided in multiple programming languages. In addition, the API provides an extensive set of services which clients can incrementally adopt to suit their needs. Each of these techniques is now discussed in further detail.

3.1 Chimera’s Hypermedia Concepts Chimera’s principle hypermedia abstractions are based on a small set of concepts. The concepts are designed to be both general (to be applicable to a wide range of applications) and flexible (such that the concepts can be used in ways unintended by the original designer). In particular the concepts are motivated by experience with the software engineering and userinterface domains. For example, in the Chiron user-interface development system [66], artists are used to present visualizations of abstract data types (ADTs). The ADT is extended unawares to enable artists to monitor calls to the ADT. This enables multiple artists monitoring a single ADT each providing a different visualization. More generally in software engineering, an application will consist of multiple artists, or viewers, creating visualizations of application-specific information, or objects. Chimera’s set of concepts follow from this discussion in a straight forward manner. Viewers manage access to a set of objects by creating visualizations of them called views. Anchors can then be created with respect to these views and these anchors can be included in links. The concepts are now discussed in detail (See Figure 3-1).

Objects

Objects are named, persistent entities whose internal structure is unknown and irrelevant to Chimera.

65

Viewer

View Anchor User

Client

View Anchor Viewer Client

Anchor

Link

Viewer View Anchor

Viewer Client

storage medium

Object

Object

Figure 3-1. Chimera’s Hypermedia Concepts. Chimera has a flexible set of hypermedia concepts. A user interacts with one or more Chimera clients. Each client has at least one viewer active within it. Viewers access objects via a storage mechanism (e.g. file system, database, object management system) and create graphical views depicting them. Anchors can be created on these views either automatically by the viewer or explicitly by the user. Links define relationships between these anchors. Chimera’s links are modeled as sets with each anchor in the set accessible by link traversal to the others. Attributes can be associated with each concept, but are not shown on the diagram to avoid clutter. A hyperweb consists of all of these elements.

Viewers

Viewers are named active entities that display objects. The operations provided by a viewer are specific to the viewer and the type of objects it displays. Typically viewers provide browsing, creation, and editing functionality on objects within their domain.

Views

Views denote a pair ( v, o ) where v is a viewer for an object o . Note that an object may be displayed by more than one viewer, and thus participate in multiple views.

66 Anchors

Anchors are defined and managed by viewers in the context of a view. An anchor tags some portion of a view as an item of interest. Anchors are tailored by a viewer to the particular view of the object being displayed. Unlike hypermedia systems which require direct anchor to object mappings [29] with anchors often embedded in the objects themselves [7, 8], Chimera anchors may represent some purely visual component, such as a button or other interface element. In general the creation and deletion of anchors on the view of an object leaves the underlying object unmodified, still usable by tools unaware of Chimera’s existence. Sometimes, however, modifying the underlying object is unavoidable. Factors contributing to this include the tightness of integration between third-party applications and Chimera and the level of sophistication in a viewer’s mapping function between anchor information and the views it creates.

Links

A link is a set of anchors. All anchors in a link are related to each other. Thus a link traversal can start at any member of a link and lead to any other member or members. Empty links and singleton links are supported. Links are first–class objects in Chimera and a viewer can be constructed to display them. Anchors may be created on these link views and included in other links. In this manner Chimera supports “links to links,” an important abstraction which supports construction of large, complex hyperwebs.

67 Attribute-Value Pairs Each instance of a Chimera hypermedia concept can have an arbitrary number of attribute–value pairs associated with it. An attribute–value pair consists of two associated strings where one string contains the attribute’s name, the other its value. Attribute–value pairs are commonly used in hypermedia systems to provide run–time semantics or behavior for hypermedia entities [13]. Example uses of attributes include naming links, providing access control information, or filtering information based on type.

Clients

Clients contain one or more viewers. The client concept allows the accurate modeling of multi-threaded applications interacting with Chimera. The client concept provides a clear demarcation between the responsibilities of a Chimera client and the responsibilities of its viewers.

Users

Users interact with the viewers of Chimera clients. The user concept allows Chimera to more accurately model its link to the external world.

Hyperwebs

A collection of objects, viewers, views, anchors, links, clients, and users along with their attributes is a Chimera hyperweb. A hyperweb is similar to Leggett’s hypermedia [39] and Halasz’s hypertext [31].

68 3.1.1 Evolution of Concepts Based on experience with developing clients for the initial version of Chimera, the set of hypermedia concepts has evolved in an incremental fashion. The changes represent an increase in the support for heterogeneity as well as an increase in support for simplicity (a design principal which states “it should be simple to accomplish simple tasks”).

Composites. The notion of a composite has been added to Chimera. A composite is defined as an object which can contain (references to) other objects. Composites are implemented as a subclass of objects, so a composite is itself an object. This implies that composites can contain other composites and be included in views. Composites are necessary to more accurately support viewers which create complex views based on the information stored in a set of objects. The increased accuracy of the model enables a more natural specification of the views displayed by a viewer and the ability to route hypermedia events to specific portions of a composite view. As currently defined, Chimera’s composites do not address all the issues specified for composites in [25], however they serve as a placeholder for evolving full support of composites in future versions of Chimera.

View-Independent Anchors. In the initial version of Chimera, anchors are viewspecific entities. This followed from the notion that a viewer knows best how to tailor an anchor to suit the view it is displaying. However, in practice their are multiple viewers which know how to display the same object types and it would be advantageous to have anchors created by one viewer for its view appear in a view generated by a different viewer over the same object. A view-independent anchor is thus an anchor which is associated with an object

69 which should appear in all views of that object. this implies that the format of the anchor (in Chimera terms, the format of an anchor refers to the format of the information contained in the anchor’s associated attributes) must be standardized such that multiple viewers can interpret the information and display the anchors within their views. Now views have a set of view-specific anchors and a set of view-independent anchors. The former set will usually take advantage of a particular viewer’s advanced display capabilities for a particular object type. For instance, an image program may be able to display spline-based anchors over its images in addition to the standard rectangular anchors.

Views as Whole-Component Anchors. The notion of a whole-component anchor is one in which the anchor refers to an entire component (or in Chimera, view) rather than a specific internal region of the component. In the initial version of Chimera only anchors could be added to links. So in order to implement a whole-component anchor, a viewer would register a view and then create a single anchor which the viewer would interpret as a reference to the entire view. If the viewer also supported anchors internal to the view, the viewer would have to insert special code to recognize the whole-component anchor. This approach is inefficient in terms of space since an anchor must be created for each view to essentially “stand in” for the view. The second version of Chimera now permits views to be added to links with the associated semantics that these views represent whole-component anchors. This approach is more simple and allows anchors to be used exclusively to denote some internal region or component of a view.

70 Locking Mechanism. A simple locking mechanism has been added to provide additional support for multiple users. In the initial version of Chimera, multiple users could login to the same Chimera server, however the server provided no assurances that a user’s updates to the hyperweb would not overwrite the changes made by another user. Now, Chimera concepts can be locked by a particular viewer for a particular user and other users will not be able to modify those concepts until the original viewer unlocks them. The implementation of the locking mechanism is extremely simple and plans are in place to evolve this service into a mechanism to support both synchronous and asynchronous collaborations over a hyperweb.

Additional Events. Additional events have been added to Chimera’s API to provide viewers with more information about the actions occurring in the active hyperweb. Concept modification events inform viewers about the changes to specific concept instances. Locking events inform viewers about the status of locks held on particular concepts. Additional events are planned to help support collaborative hypermedia such as the notification of the arrival or departure of particular viewers for users participating in collaborative sessions.

3.2 Separation of Client and Viewer Chimera employs two separate techniques in its client architecture to support heterogeneity. First the concepts of clients and viewers are used to abstract away specific details of the architectures used by Chimera clients. Clients are defined as a program consisting of one or more viewers and a Chimera API. All other details of a client’s architecture are unspecified and can thus vary widely from single-threaded C clients with one

71 viewer to multi-threaded Ada clients containing multiple viewers. Second, the responsibilities of both clients and viewers are clearly defined. As long as an executable entity meets the specified requirements, they can participate in the Chimera world with no other restrictions placed on them. For instance, the client architecture in no way restricts access to external systems such as user-interface management systems, object managers, other servers, etc., in order to accommodate the heterogeneity of modern computing environments and increase the range of systems which can integrate with Chimera. Additional details of clients and viewers are discussed below.

3.2.1 Client Responsibilities A client is responsible for establishing, maintaining, and relinquishing a connection with the Chimera server. This connection is typically managed by the Chimera API but the client is responsible for calling the relevant routines to initiate the management. All viewers in a client share this single connection to the server. Thus, all hypermedia requests and responses flow through this connection. The next responsibility of the client is the routing of hypermedia events. The client receives events from the Chimera API by specifying an event handler during client initialization. The Chimera API calls this event handler when a hypermedia event is received from the Chimera server. Since there can be more than one viewer per client, the server tags a hypermedia event with the destination viewer. It is up to the client’s event handler to ensure that the indicated viewer receives the event. Finally, when the server sends a hypermedia event to the client, the server marks the client as unready to receive additional events. This allows the destination viewer to handle the hypermedia event before receiving a new one. The viewer must let the client know when it is finished processing an

72 event and the client is in turn responsible for notifying the server that it is ready to receive another event.

3.2.2 Viewer Responsibilities A viewer allows users to manipulate objects by performing actions within its views. A viewer may access any external system in order to accomplish this task. For instance, a viewer can make use of a user-interface management system to provide its user-interface, or an object management system to store its persistent information.

The primary responsibility of a Chimera viewer is the mapping of the concepts object, view and anchor into its application domain. Mapping issues include how a view is presented to the user, what elements of a view can have anchors attached to them, how these anchors are created and deleted, how the presence of an anchor is indicated, and what attributes the viewer supports. The viewer can choose to store information to facilitate this mapping in a variety of ways. For example, a viewer can place display information in an attribute of an anchor to help reconstruct the anchor’s visual presentation. It can also store hypermedia information in a file that is associated with the set of objects being displayed, or it can choose to compute the mapping each time without the use of persistent information.

The second responsibility of a Chimera viewer is to correctly utilize the hypermedia protocol of the Chimera server by making the appropriate calls on the Chimera API. This includes notifying the server when it is active, registering for hypermedia events, indicating its

73 current set of views (this set will change over time based on user interaction), and handling hypermedia operations such as creating anchors and adding them to links.

The final responsibility of a Chimera viewer is the handling of hypermedia events. It should be prepared to handle the events for which it registered and provide a visual indication (if needed) that events have been processed. For instance, it could respond to a link traversal event by opening the desired object and highlighting the destination anchor. When a viewer has finished processing an event, the viewer must also notify the client of this fact so the client can indicate to the server that it is ready to once again receive hypermedia events.

3.3 Dynamic Link Semantics An OHS’s support for heterogeneity can be increased by providing mechanisms to allow developers and end-users the ability to specify the behavior of link traversals, e.g. link semantics. The argument in support of this issue is analogous to the one made above for the benefits of reducing the assumptions made about the clients of an OHS. While a single general behavior for link traversals might satisfy the minimal needs of a majority of the clients, invariably the pre-defined behavior will fall short in terms of sophistication in some application domains. For instance, the original version of Chimera provided only one behavior for link traversals. Given the specification of a traversal’s starting point, all possible destinations are identified and sent notification messages. This behavior implements the basic navigational idea behind hypermedia however it can produce disorienting effects to a user who is unclear on the structure of the active hyperweb. For instance, the link traversal from an anchor which has n associated destinations will potentially cause the appearance of n new

74 windows as the destination viewers bring up the requested views. The user’s display can quickly become cluttered hindering the user’s ability to understand the results of the traversal. An alternative style of link semantics would specify that users be informed of the number of destinations before the traversal occurs and allow the user to specify the destinations of interest.

There are several ways to provide and specify link traversal semantics. SP3 [39] adopts a process-based approach in which links are realized at run-time as executable programs. The behavior of a link is thus determined by the semantics of its associated process. Another approach is to use a scripting language to enable users to write small programs which are executed during traversal. Multicard [57] makes use of the M2000 scripting language for exactly this purpose. A link is modeled as a communication port between two entities (typically client and server). After the link is established, either party can pass a script across the port to be dynamically interpreted on the other side. The behavior associated with these scripts define the semantics for the traversal. The approach explored in the second version of Chimera is one of server plug-ins.

A developer or user can create a server plug-in that defines a new behavior for link traversals and dynamically load the plug-in into an executing Chimera server. Multiple plugins can be loaded concurrently, and the Chimera API can be used to select among the various plug-ins to govern the behavior of a link traversal (see the initiateTraversal operation in Appendix A). These plug-ins are written as Java classes and make use of an internal Chimera server API which enables them to receive link traversal requests, scan the active hyperweb for

75 relevant information, and generate link traversal notifications to destination clients. Since each plug-in can take advantage of the full range of Java capabilities and libraries, a plug-in can create a user-interface, establish network connections to remote servers, and perform arbitrary computations. Hence a plug-in can be used to access information located in any external information store, and a user-interface can be provided to obtain information from the user if necessary. For instance, an interface can be provided to allow a user to enter SQL queries on a remote database. A plug-in’s user-interface is accessible to end-users since the Chimera server executes within the user’s environment.

Web-based Chimera clients (see Section 4.2.3), such as Java applets, can also take advantage of server plug-ins, however the plug-in must be available on the machine where the applet is executing so that its user-interface can be presented to the user. The plug-in’s userinterface can not be executed by the Chimera server in this situation, since Web-based Chimera clients must access a remote Chimera server due to the security restrictions imposed on them. To support this situation, the plug-in is written such that the Chimera API executes the user-interface portion of the plug-in on the applet’s host machine and then sends any input from the user to the computational portion of the plug-in which is being executed by the remote Chimera server.

3.4 Multi-Platform Support Another aspect of supporting heterogeneity for open hypermedia systems is producing a system which can provide services on multiple operating system/hardware platforms. There are two facets to this type of support. First, hypermedia services can be made available to

76 clients on non-supported platforms via the interprocess communication services provided by the application program interface. Second, the hypermedia servers can be ported to multiple platforms in order to run natively in each environment. Clearly the first approach involves less effort than the second. Each platform is likely to have an implementation of network sockets available. At the very least a C-based API can be built for multiple platforms. A third alternative is to use a programming language which has the ability to execute the same program on multiple platforms without modification. For instance, Smalltalk programming environments [53] have long had this capability, and more recently, the programming language Java has appeared with this capability.

The initial version of Chimera due to a variety of implementation choices was confined to the SunOS and Solaris operating systems running on SPARC hardware. The second version of Chimera has been implemented entirely in Java and now provides support for the first and third strategies described above. The Java APIs for the Chimera 2.0 servers can be executed on one platform communicating with servers running on another platform. In addition, each of the three Chimera servers can execute on any Java supported platform.

3.5 Multi-Lingual APIs The Chimera API is a language-independent set of routines allowing the creation and manipulation of hypermedia concepts, the management of a server connections, and the handling of hypermedia events. Each language-specific version of the Chimera API must implement these routines. For each client, run-time services must be provided to establish a connection to, send requests to, and receive events from the Chimera server.

77 The API defines routines to handle the creation, manipulation, and deletion of Chimera’s hypermedia concepts. In addition, a set of query routines is offered so viewers can search for information in the hyperweb. The API is responsible for generating hypermedia requests from the calls made on it by Chimera viewers and returning the server’s response to those viewers, typically in the form of status codes or function results.

The API also defines routines that allow a client to establish and terminate a connection to the Chimera server. In addition to implementing these connection routines, the API must also provide a mechanism to notify a client if an established connection is unexpectedly terminated. One such mechanism is for the API to generate a hypermedia event (e.g. SERVER_DISCONNECTED) for the client when it detects a broken connection. The complete Chimera API is presented in Appendix A.

Finally, the API must provide a mechanism to allow a client to specify how it is to be notified of hypermedia events. Optionally, a default event handler can also be provided although it will not be able to forward events to their intended destination. This default event handler can be used to aid client development by catching all events that are not currently handled, allowing for an incremental approach to adding support for the desired hypermedia events.

The Chimera API provides the foundation upon which application programs in the user’s environment are easily integrated with the Chimera system. Use of the Chimera API provides three major implementation benefits, (1) support for multiple implementation

78 languages, (2) a reduction in the complexity of invoking operations on Chimera concepts by hiding the details of the communications protocol, and (3) a consistent event handling interface. The API consists of eighty-one entry points for the initial version of Chimera. The second version of Chimera has added additional operations and a small set of new events.

An advantage of the API approach is that low–level details of passing messages to the Chimera server are completely hidden from the clients which use the API. Instead clients invoke subprograms like register_anchor or traverse_link and the API converts these subprograms calls (and their parameters) into the appropriate messages and ships them to the Chimera server. The API also passes back any return values from the server to the calling client. This conversion is straightforward and includes creating a new message buffer, marshaling the parameters into the buffer, making the actual network call, retrieving any return values from the buffer, and deallocating the buffer.

The Chimera API also provides a consistent way to register and deregister for hypermedia events, and to specify which action to take upon reception of such an event. This allows for consistent handling of events across all applications written using a specific implementation language API. Use of API-provided facilities for event handling also makes integration of other input streams (e.g., the X protocol stream in the C API) much easier since only the API requires modification, rather than separate solutions for each application.

An API to the Chimera server for a particular language is required before that language can be used to construct Chimera clients. Chimera supports clients written in Ada,

79 C, and Java, with APIs for all three languages. Several clients have been written using each of these APIs.

The Ada API creates two Ada tasks per viewer. One task handles sending messages to the Chimera server; the second task handles receiving hypermedia events from the server. These tasks operate independently and maintain separate Unix sockets. This allows multiple connections to the Chimera server within a single Unix process. The Ada API has proven to work successfully with other client–server systems, the most notable being a simultaneous connection by one viewer to a Chimera server, a Chiron server, and a sound server.

The C API allows C programs to use Chimera services within a single Unix process. Two sockets are maintained by the C API, requiring application writers to take responsibility for the scheduling of message transmission and event reception. Since many programs using the C API also use X Windows to produce their user interface, support was added to receive Chimera events from within an Xt event loop. Chimera events are handled using a callback mechanism. To date, six separate C programs have been written which are simultaneously Chimera and X clients within a single Unix process.

The Java API is a set of Java classes allowing access to Chimera services within multithreaded Java applications (and applets). The Java API creates two threads per viewer similar to the Ada API; one thread sends messages to the server and the other receives events from the server. Java applications implement an interface defined by the Java API so that hypermedia events can be routed to them.

80 The second version of Chimera is written entirely in Java and provides Java APIs for the hyperweb manager, hyperweb server, and Chimera server. A major change in the internals of these APIs is that the Q messaging system [43] which was used in the three APIs described above was abandoned. The APIs now connect directly to TCP sockets and manage their own message marshalling and network I/O. The primary reason for dropping the Q system is that its Java implementation relied on the use of native C libraries which are available for only a small set of platforms. This defeats the goal of providing Chimera on multiple operating systems. A C API based on the new Java Chimera server API will be implemented such that all of the existing Chimera 1.0 clients can be moved to the second version of Chimera.

3.6 Incremental Adoption A principle Chimera design goal has been to present a low-entry barrier to use. This goal has been achieved as a consequence of the techniques described above. First, Chimera’s conceptual abstractions are general and the mappings between them and an application domain is often intuitive. Second, the responsibilities of clients and viewers are clearly defined and provide a tangible “check-list” for developers while performing an integration. A framework has recently been defined to further aid in the integration task [67]. Third, the Chimera API implements the low-level details of interprocess communication freeing the developer to concentrate on adding hypermedia operations to his application. Finally, the set of API operations and event handlers that need to be implemented to perform a basic integration with Chimera is extremely small. At a bare minimum, a client must call nine operations (active_view, active_viewer, add_anchor_to_active_link, register_anchor, register_interest, register_object, register_view, register_viewer, and traverse_link) and implement

81 two event handlers (active_link and link_traversal) in order to provide the essential services of creating anchors, adding them to links, and initiating and receiving link traversals.

Additional services such as providing a user with the ability to select among the destinations of a link traversal, create and modify links, searching the hyperweb, and implementing additional event handlers can be added incrementally as needed.

CHAPTER 4: Integration with the WWW

A recent research trend in open hypermedia systems is integration with the World Wide Web [8]. Integration can be achieved in a variety of different ways (as discussed in Section 2.2). Unique to my work is research exploring the use of WWW protocols within an open hypermedia environment. The motivation for this approach is to leverage the strengths of the WWW protocols (and avoid reinventing the wheel) to enable an open hypermedia system to scale-up to wide area networks, provide services to Web-based clients, and employ standard Web user-interaction styles. This expands the reach of the open hypermedia system while retaining the traditional benefits of open hypermedia systems such as link consistency and management, inter-application linking, and separation of hypermedia structure from application content [32]. In addition, once the integration of WWW protocols is complete, the open hypermedia system is uniquely positioned to provide the Web with advanced hypermedia services.

I have developed a conceptual architecture for this type of integration (see Figure 4-1) which is both modular and scalable. It is essentially a generalization of the architecture utilized by the initial version of Chimera [2] with the addition of Web-based architectural elements. In this Chapter, I describe the conceptual architecture and then discuss its implementation in the second version of Chimera [5]. In the implementation section, I describe how the conceptual architecture is modified to support existing restrictions on Web-based clients (e.g., Java applets), how the architecture addresses limitations in the initial version of Chimera,

82

83 details of the components used to implement the architecture, and a Web-based Chimera client made possible by this new deep integration with the Web.

4.1 WWW-OHS Integration Conceptual Architecture The architecture presented in Figure 4-1 divides the conceptual space into two types of environments. The first environment is a user’s workspace while the second environment is a modification of the traditional Web site. A user’s environment contains four types of architectural elements: applet, client, client server, and Web browser. The modified Web site contains seven architectural elements: applet, CGI script, document, hyperweb, hyperweb manager, hyperweb server, and WWW server. The architecture abstracts away all other conceptual and implementation details. For instance, each environment can consist of a set of locally networked machines with instances of the architectural elements distributed throughout the LAN. Each environment is now described.

4.1.1 User Environment A user environment corresponds to the typical heterogeneous computing environment described in the Introduction. In the conceptual architecture, the multitudes of applications, data types, and processes are abstracted away to the bare essentials required to describe open hypermedia services. The notion of multiple users is not abstracted away but explicitly considered in the architecture. This serves as a placeholder for supporting cooperative hypermedia (see Section 2.1.4 for a discussion of Chimera’s existing support and future plans for collaborative hypermedia). However, CSCW issues such as how users

84

User environments Client

WWW sites WS

Applet

Documents CGI scripts Applets

Client

Web Browser

HWM

Client

CS

HWS

Hyperwebs

CS

Client Server

HWS

Hyperweb Server

HWM

Hyperweb Manager

WS

WWW Server

Figure 4-1. OHS-WWW Integration Conceptual Architecture.

communicate or establish cooperative sessions with each other is not discussed here. The remaining architectural elements include:

Applet. An applet refers to the various types of applications which can be downloaded from a remote Web site and executed (typically) within the environment of a Web browser. Examples include ActiveX components [46], Java applets [65], Juice applets [20], and ShockWave presentations [40] among others. They are included in the architecture since the OHS’s integration with the WWW enables support for these types of clients. Applets, thus, share a lot of the same characteristics as the client architectural element described next. The primary difference typically involves implementation restrictions placed on applets due to security considerations.

Client. All open hypermedia systems provide services to clients which have some degree of awareness of the existence of the open hypermedia system [15, 67, 72]. These clients implement the OHS’s hypermedia protocol which enables them to communicate with the

85 OHS and handle events sent from the OHS. The client elements in Figure 4-1 can be considered composites since a particular client may actually be a (client, wrapper) pair in which the wrapper is implementing the OHS’s hypermedia protocol on behalf of some unaware client. This technique is often used to integrate applications which have some form of external API. The integration of Web protocols impacts these clients in that the Web’s URL protocol [9] is used to specify remote hyperwebs and their contents. The client server (discussed next) interprets these URLs to retrieve the specified information.

Client Server. The clients of an open hypermedia system require an architectural element to track their existence, receive, route, and implement their requests, deliver events to them, and invoke new clients as required by link traversals. This element is referred to as the run-time layer by Dexter [31]. In the conceptual architecture, these run-time services are provided by the client server. In the conceptual architecture, the client server acts as a gateway to the distributed hyperwebs of the open hypermedia system. It hides the details of retrieving information stored in the hyperwebs, and can act as a local cache for this information to improve performance in much the same way that Web browsers cache Web documents in order to speed subsequent access. In fact, users and clients utilize the URL protocol to specify remote hyperwebs they wish to access similar to how URLs are used in Web browsers to specify interest in Web documents. The client server’s responsibilities also include creating links between hyperwebs, and implementing link traversal.

Web browser. A standard Web browser is part of the conceptual architecture for two reasons. First, it serves as an execution environment for applets. Other execution

86 environments exist (e.g., Java’s appletviewer) but the browser is the one most typically used. The second reason is due to the use of the URL and HTTP protocols by the architectural elements located in Web environments (discussed next). The browser can be used as normal to access the documents, CGI scripts, and applets via the WWW server on the remote Web site. In addition, it can be used to make requests on the hyperweb server and hyperweb manager. These requests can range from accessing hypermedia services and displaying status information to configuring the behavior of these servers. In this way, the open hypermedia system is accessible to the user from within a familiar environment, and avoids having to learn new tools specific to the open hypermedia system.

4.1.2 Web Environment A Web environment is a variation on the traditional Web site of a single Web server providing access to a set of documents, CGI scripts, and applets. The variation involves adding components of an open hypermedia system to the site to provide additional hypermedia services and to store hypermedia information. The components of a Web environment include:

Applets. This element indicates that applets (which can participate as full Chimera clients) are typically stored in a Web environment. They are made available to users when they download into their Web browser a document which contains an embedded (or dynamically generated) reference to an applet.

87 CGI scripts. This element refers to any application which can be invoked by a Web server to help it respond to an HTTP request. Common Gateway Interface (CGI) scripts are the most common of these types of applications. However as used in the conceptual architecture this element can be realized by server-side JavaScript [65], Java servlets [64], and server plug-ins. This element is included in the conceptual architecture since these scripts can be used to access information stored in the hyperweb manager or hyperweb server as input to the computation being performed by the CGI script. These computations typically involve the dynamic generation of HTML documents. One possible use for this capability is to process URL requests sent from a Web browser for the contents of hyperwebs stored in the Web environment.

Documents. Documents are stored in the Web environment and retrieved by WWW Servers. They are included as an architectural element since Web-based clients may use the Web environment as a storage facility. In addition, the open hypermedia system may store its documentation, status information, banner and search keywords (so that Web crawlers can locate sites enhanced by the open hypermedia system), search and query forms, etc. as static HTML documents within a standard location of the WWW server’s namespace.

Hyperwebs. Hyperwebs are the databases employed by the open hypermedia system to store hypermedia-related information (such as anchors and links). They are located under the namespace of the WWW server. This associates with them a URL by which the hyperweb and its contents can be uniquely referred. In addition, since URLs are hierarchical in nature, the open hypermedia system can leverage this fact to provide semantics to the hierarchical

88 namespace. For instance, can refer to the first sub-web of the hyperweb named web1. Finally, as discussed above, by placing the hyperwebs under the namespace of the WWW server, CGI scripts can be written which resolve requests on the hyperwebs into calls on the hyperweb manager or hyperweb server to retrieve the appropriate information.

Hyperweb Manager. The hyperweb manager is a component of an open hypermedia system responsible for creating, deleting, copying, and renaming of the hyperwebs located on its site. In addition, it is responsible for keeping track of the connection information of the hyperweb server. This enables the hyperweb server to be located on any machine contained in the Web environment. The hyperweb manager, on the other hand, is located on a pre-defined communications port on the same machine as the WWW server. This strategy provides the hyperweb manager with the same URL (except for the port number) as its associated Web server making it easy for clients to discover and connect to it. The hyperweb manager implements responses for a small set of URLs. Typically this set of URLs will provide details about the hyperwebs located on the site and the connection information for the hyperweb server.

Hyperweb Server. The hyperweb server is a component of the open hypermedia system responsible for reading and writing the information contained in the hyperwebs. It also provides access to this information to the client server (and hence the clients) of the user’s environment. In addition, as clients send requests (via the client server) to manipulate the

89

User environments Client

WWW sites WS

Applet

CGI scripts HWM

Client

Web Browser HWS

Client

CS

Documents

Applets Hyperwebs

CS

CS

Client Server

HWS

Hyperweb Server

HWM

Hyperweb Manager

WS

WWW Server

Figure 4-2. OHS-WWW Integration Implementation Architecture.

information contained in the hyperweb, it is the hyperweb server which implements the specified request.

WWW Server. The WWW server is responsible for providing access to the applets, CGI scripts, and documents contained within the Web environment.

4.2 WWW-OHS Integration Implementation Architecture The implementation of the conceptual architecture is explored in the second version of the Chimera open hypermedia system. The implementation architecture (see Figure 4-2) was modified minimally in order to accommodate the current security restrictions placed on Java applets. The modification involves placing a set of client servers within the web environment to service the requests of applets. The reason for this change is that Java applets are restricted to network communication with only the machine from which they are downloaded. This means that the applet cannot access the client server located in the user’s environment. As a result of this change, the hyperweb manager was modified to track the

90 connection information for the client servers located within the Web environment. Applets make use of the hyperweb manager’s well known port number to contact it and request the connection information of a client server. Once this information is retrieved they connect to the client server which then acts as a proxy for the applet and can connect to any Chimeraenhanced website without restriction.

A side-effect of this modification is that applets are no longer in synch with the other clients of the user environment in terms of the active hyperweb (because they are communicating with different client servers which are not necessarily synchronized). As discussed in Section 7.1.2, one approach to solving this problem is to have the two client servers establish server-to-server communication and to remain in synch with one another. Another solution is to make use of trusted applets. Trusted applets have an associated digital signature which provides some means to evaluate whether the applet contains any malicious code within it. The theory behind trusted applets is that if the user receives the applet from a trusted source then certain security restrictions on network communication or access to the hard disk can be lifted. Trusted Chimera applets which are granted full network access can establish a connection to the local environment’s Chimera server and thus be in synch with other Chimera clients in the user’s environment. In Chimera 2.0, only support for Java applets has been provided, however similar solutions are probably needed to support other applet types.

The rest of this Chapter is devoted to exploring various aspects of the implementation architecture. First, limitations of the initial version of Chimera are discussed with the intent of

91 demonstrating how they are addressed by the implementation architecture. Second, implementation characteristics of the second version of Chimera are described and then a Web-based client enabled by this integration of the WWW into an open hypermedia system is described.

4.2.1 Applying the Implementation Architecture to Chimera 1.0 The initial version of Chimera contained some implementation restrictions which hindered the distributed aspects of the system. In order for a user to access a hyperweb in Chimera, the user’s account, the user’s Chimera clients, the Chimera server, and the desired hyperweb all had to reside on the same network file system. This restriction limited Chimera’s support for distribution to a LAN. The reason for this restriction involved the ability to access various text files which contained the location of the hyperweb and the connection information for the Chimera server.

In addition, Chimera 1.0 had a number of user interface quirks which prevented new users from learning the system quickly. Chimera hyperwebs were difficult to manipulate and use effectively. The only way to reference a hyperweb was with its absolute path name. Links between hyperwebs were not supported, forcing users to place all information into one hyperweb rather than distributing information across related hyperwebs. Finally, Chimera provided no mechanism to discover the existence of hyperwebs created by other users. All of these issues are addressed via integration with the Web.

92 First, Internet distribution is achieved through the use of URLs. These URLs contact the hyperweb manager to retrieve a server’s connection information, which used to be specified in text files on a shared file system. HTTP is used to transmit these URLs and their associated responses. Once the connection information is retrieved, a more compact protocol native to Chimera is used for faster performance. Second, the ability to discover new hyperwebs is enabled via the hyperwebs URL which returns information on all hyperwebs available at a particular site. The problem now shifts to discovering Chimera-enhanced websites. However this problem can easily be solved with existing Web mechanisms, such as a query on an Internet search engine or a Web page at the Chimera website which tracks all known sites. The former is possible since the root URL of a Chimera site (i.e. is

configured to return a page containing keywords indicating a

Chimera-enhanced site.

Finally, hyperwebs are easier to manage and understand due to their now explicit hierarchical structure and the interface provided by the hyperweb manager which provides operations such as create, delete, rename, and get info. Links between hyperwebs are supported as well. In the initial version of Chimera, the Chimera server could only manage one hyperweb at a time. This made it impossible for it to create links which spanned hyperwebs. Now with the new separation between the client and hyperweb servers, a client can have a client server connect to multiple hyperweb servers and begin the construction of a new link. Each anchor in the link is attributed with the URL of its hyperweb. A copy of this link is then placed in each hyperweb. At a later time, the client server can start a link traversal over the link from any hyperweb and use the URLs associated with each anchor to traverse to the correct

93 hyperweb. This solution is similar to the solution used by HyperDisco as described in [75]. The primary difference being the use of a URL to indicate the location of remote hyperwebs in place of a workspace name.

4.2.2 Implementation Details The three servers of the architecture are implemented using a common Java framework. The framework handles the details of making each server multi-threaded with the ability to handle multiple native and HTTP requests from different clients in parallel. Each server can then specialize the framework in order to implement their services and the set of URLs to which they generate a response.

Currently, only the hyperweb manager responds to HTTP requests. For instance, queries

the hyperweb manager for the connection

information about the client servers in its domain. A URL of the form is

used to determine the names of the hyperwebs

available for a site. The URL retrieves the connection information for the site’s hyperweb server. This ability of the hyperweb manager to receive HTTP requests directly is similar to the gateways employed by Hyper-G [42] to allow standard Web clients access to its hypermedia information. The primary difference is that the hyperweb manager does not fully implement the responsibilities of a WWW server. Instead it only responds to a small set of URLs and ignores all other requests.

94

User space Client

Applet Web Browser

Client

Chimera-enhanced websites WS HWM 2 HWS

Client

1

3 CS

Documents CGI scripts Applets Hyperwebs

5

4

CS

CS

Client Server

HWS

Hyperweb Server

HWM

Hyperweb Manager

WS

WWW Server

Figure 4-3. Interactions within the Implementation Architecture.

Figure 4-3 shows some of the interactions possible in the implementation architecture in order to summarize the details provided in Sections 4.1.1 and 4.1.2. (1) A user can invoke Chimera clients which interact with the local client server. (2) The local client server presents a user-interface which allows the URL of a Chimera website to be specified. The client server connects to the hyperweb manager of the site to determine the connection information of the site’s hyperweb server. (3) It can then connect to the hyperweb server and allow the user to select among the available hyperwebs. (4) Once selected, the hyperweb server loads the hyperweb into memory allowing it to be manipulated by the active clients. (5) The hyperweb manager, which has a pre-defined port number, can handle direct HTTP requests for information about the site. The use of applets is shown in Figure 4-5 and discussed next.

4.2.3 Support for Web-Based Clients The deep integration with the Web achieved by the implementation architecture allows the support of Web-based clients. This section discusses the problems encountered in developing a Web-based client whose purpose is to provide pervasive access to Chimera

95

Figure 4-4. The Chimera Presence Applet. The applet presents a user-interface divided into panes. The Servers pane allows users to specify the desired Chimera website while the Webs pane allows them to select among the site’s hyperwebs. The Links pane (shown above) displays all of the links contained in the hyperweb and provides operations to manipulate links, initiate traversals, examine a link in detail, and add or remove the Web page to or from the selected link.

services from within the confines of a standard Web browser. The idea behind the client is to attach a Java applet which provides access to Chimera’s services to every Web page a user visits. The user can create and manipulate links, switch between hyperwebs, and initiate link traversals all from within the applet’s user-interface (see Figure 4-4). Since the Java virtual machine has been ported to a variety of platforms and Web browsers, this Web-based client provides Chimera services cross-platform for the first time. (Another aspect of Chimera 2.0’s cross-platform support is that the Java servers can be run on any Java supported platform.)

A solution which applies several Web mechanisms in tandem, including the implementation architecture, is developed (see Figure 4-5). It is important to point out that the problems described below are primarily due to the nature of the client’s goal: to enhance the hypermedia services of the WWW. More simple Web-based clients, such as an applet

96

User space

Chimera-enhanced website

1 Applet Web Browser

2

WS 5 6 7

HWM

external website 3

Presence CGI 4 Presence Applet

WS

Hyperwebs HWS 10

9 CS

8

The legend for this diagram is the same as in Figure 4-3. Step 8 demonstrates the client server connecting to the local website’s hyperweb manager. This was done to simplify the diagram. In reality, the applet can direct the client server to connect to any Chimera-enhanced website since it passes a URL to indicate the desired site.

Figure 4-5. Applet Interactions within the Implementation Architecture. The process outlined above is as follows: (1) The user fills out an HTML form specifying their user name and target destination. (2) The web server receives this form and invokes its associated cgi-script. (3) The cgi-script retrieves the target document, modifies its anchors (see Figure 4-6) and (4) inserts the applet tag at the end of the document. (5) As a result the applet is downloaded into the web browser. (6) After initialization, the applet contacts (via an HTTP request) the hyperweb manager located on the server. (7) The hyperweb manager provides it with the contact information for a client server which it then contacts. (8) After determining the target site (either built in to the applet or provided by the user), the client server contacts the target’s hyperweb manager. (9) This enables the user to select a hyperweb, which is accessed via the site’s hyperweb server. (10) If the hyperweb is not currently active, the hyperweb server loads it into memory. When traversing to a new page, the cgi-script is contacted once again and the process repeats. However, this time the applet defaults to using the website and hyperweb selected on the previous iteration.

providing anchors over the objects in its window are handled trivially by the implementation architecture.

The first stumbling block is encountered in Java’s applet mechanism due to the security restrictions placed on applets. First, an applet is not allowed to get the contents of a URL because URL content handlers fall outside the set of legal classes for applets. This prevents the applet from directly utilizing the URL mechanism described above to contact the hyperweb manager. Second, an applet is only allowed to establish a socket connection to the machine from which it was downloaded. This means that the applet can only be attached to pages which come from a Chimera-enhanced website. Third, an applet is not able to communicate state between instances of itself located on separate Web pages. Among other

97 things, this implies that each time the user traverses to another page, they will have to respecify information such as their user name and the current website and hyperweb.

The solution involved three parts. First, the applet implements the HTTP request on the hyperweb manager directly. Second, a CGI script is used to attach the applet, called Chimera Presence to a Web page. Third, an HTML form is used to initialize the CGI script with the user’s name. In turn, the CGI script sets an HTTP cookie to save the name of the user for each subsequent applet invocation. Each part of the solution is now described.

The problem of an applet not being able to access the contents of URLs is solved by implementing the HTTP request on the hyperweb manager directly. The hyperweb manager can be contacted since it lives on the Chimera-enhanced website from which the applet was downloaded. The hyperweb manager makes use of a pre-defined port number avoiding the need for a name service in order for clients to locate it.

The CGI script applies a technique similar to the service provided by . The

CGI script is given one parameter: the URL of a Web page. The

CGI retrieves the contents of the specified URL, modifies the links within to be prefixed by the URL of the CGI script, and appends the HTLM necessary to include the Chimera Presence applet at the end of the page (see Figure 4-6).

The CGI script solves the latter two problems mentioned above in three steps. First, the CGI script modifies Web pages to always call the CGI script for subsequent link traversals.

98

Before: Example One Please visit the Chimera web page. After: Example One Please visit the Chimera web page. The Chimera Presence Applet

Figure 4-6. Output of the Chimera Presence CGI Script. This figure demonstrates the output of the CGI script associated with the Chimera Presence applet. The CGI script inserts its URL as a prefix to any URLs contained in the target HTML document, and inserts the applet at the end of the document.

This allows the CGI script to attach the applet to each page the user visits via direct link traversal. In this manner, the applet appears on each page providing pervasive access to Chimera. The applet will not appear in the case where a user enters a URL directly into the Web browser. One solution to this problem is through the use of an HTML form attached beneath the applet. Regardless, the ability to remove the presence of the OHS is needed so that the user has the power to choose when to access these services.

Second, the script executes on a Chimera-enhanced website which means the applet will be able to communicate with the hyperweb manager and client server on that site. Third, the CGI script sets applet parameters to specify the current page and the user’s name. It receives the user’s name when first invoked by the HTML form, and by the HTTP cookie that it sets on each subsequent invocation. As the current site and hyperweb are changed by the user from within the applet, the applet stores this information with the hyperweb manager indexed by user name. When invoked subsequently, the applet retrieves the current values for

99 the site and hyperweb from the hyperweb manager using the user name supplied by the CGI script. This baroque process is necessitated by the fact that the Java security manager blocks an applet from determining the name of its user. The proposed trusted applet mechanism of Java may help to eliminate this part of the solution in the future.

4.2.4 Implications It is important to reflect on the implications of this research into integration techniques with the WWW. The obvious benefits are the global distribution provided by WWW protocols and the re-use of standard Web user-interface mechanisms. The former allows servers, clients, and data to be located anywhere on the Internet, while the latter allows an OHS to leverage a user’s experience with the Web by presenting a similar user-interface. A more important benefit is the deeper integration of hypermedia services into a user’s environment achieved when these augmented OHSs are used as a basis for delivering OHS functionality to the Web.

However the difficulties encountered in creating the Web-based client which aimed to enhance the hypermedia services of the WWW has lessons for both the hypermedia and Web communities. In particular, it stretches the limits of the intended design of URLs, Java applets, and cgi-scripts by producing a hypermedia application which depends on their combined use, and flawless interaction with an underlying OHS. It demonstrates to the hypermedia community that the Web is a viable platform for experimentation whose reusable mechanisms are cross-platform and accessible to most end-users. The WWW community

100 benefits both from seeing the increased power which can be brought to the Web as well as receiving feedback on their existing mechanisms.

CHAPTER 5: Integration of User-Interface Toolkits

One area of research in open hypermedia systems explores new techniques for integrating hypermedia services into applications (especially existing applications) via the OHS. Existing techniques and a framework for modeling client integrations are reported in [15] and [67] respectively. The primary focus of these techniques are integrating one application at a time into the OHS. My research provides a technique which scales the focus from one application to entire classes of applications. In particular, the class of applications, which my technique integrates, is applications that implement their user-interface via the services of a user-interface toolkit. This class of applications is further decomposed into applications which take advantage of a particular user-interface toolkit. The key idea behind this new technique is that if a user-interface toolkit is modified to know of the existence of an open hypermedia system and to provide access to the OHS’s services via the toolkit’s widgets, then any application which uses the integrated toolkit’s widgets will provide, automatically, a default level of hypermedia services to the application’s end-users. This approach leverages the strengths of the toolkit approach on to the hypermedia services. These strengths include:

Consistency. The hypermedia services provided by the toolkit’s widgets behave consistently within a single application and between applications constructed using the integrated widgets.

101

102 Transferability. Users can learn hypermedia skills using one toolkit application and then rapidly transfer those skills to using the hypermedia services of another toolkit application.

Scalability. New applications which use the integrated toolkit provide a default set of hypermedia services. Existing toolkit application can be modified to take advantage of these services as well. The result is a large set of hypermedia-aware applications. As enhancements are made to the services provided by the integrated toolkits, all applications automatically gain access to those enhancements. In the same fashion, a bug-fix in the toolkit benefits all integrated applications.

Robustness. The handling of OHS-related errors can be localized in the toolkit and kept out of the integrated applications. This allows application developers to focus on their application domains and not hypermedia. In addition, for errors which require end-user involvement, the toolkit, by its very nature, can provide a user-interface to the user to receive feedback on handling the error. This user-interface takes advantage of the consistency and transferability benefits listed above since users will quickly become familiar with the toolkit’s error handling mechanism.

The rest of this chapter describes the technique in detail and then discusses two prototype instantiations of the technique and the lessons learned from implementing the technique.

103

5.1 Toolkit Integration Technique The toolkit integration technique (TI technique) [4] applies the conceptual architecture shown in Figure 5-1. The major components of the conceptual architecture are the integrated toolkit, the OHS, and the set of applications using the toolkit. The integrated toolkit consists of the original user-interface toolkit, a set of extended widgets, and a hypermedia infrastructure. It is important to note the technique’s potential for toolkit independence, since any user-interface toolkit can likely be integrated by building these extensions. The variable across toolkits will be the amount of effort a toolkit integrator expends to achieve the required extensions. For instance, a toolkit constructed with an object-oriented programming language is fairly easy to integrate. The extended widgets reuse the appearance and behavior provided by the original widgets via inheritance and can be mixed and matched with the original widgets via polymorphism. On the other end of the spectrum, a library-based toolkit will require more effort since the extended widgets may have to reimplement some or all of the original widgets and employ potentially toolkit-specific mechanisms to compose these new widgets into an interface with the original widgets. The developmental effort for the former toolkit is minimal while the effort for the latter is, most likely, prohibitive. Section 5.1.3 addresses this issue by modifying the conceptual architecture to facilitate “plug-and-play” of certain architectural elements.

The hypermedia services provided by this technique to applications constructed with the integrated toolkit include navigation, search, history, and bookmarks. Some of these services are provided by every extended widget while others are provided only by specialized widgets. The upper bound of possible services is defined by the functionality of the

104 underlying OHS. The lower bound will vary depending on the affordances of the widget. Thus, for instance, a button widget might only be able to initiate or receive link traversals, whereas a canvas widget might provide a popup menu to access services such as bookmark creation or search and query. Specialized widgets can keep track of a user’s navigation path or display a user’s bookmarks. Although not all hypermedia operations may be provided by the widgets, this does not prohibit the user from accessing these services. For instance, some services may only be available via specialized clients of the underlying OHS such as hyperweb viewers or link editors. These applications can be used in combination with toolkitconstructed applications to provide users with a complete range of hypermedia functionality.

The responsibilities placed on an application using the integrated toolkit are minor. As discussed in the next section, an application must supply context information to the extended widgets during initialization. This information is required by the underlying OHS. The only other responsibility is providing a callback routine to the toolkit to respond to link traversal events which require a new object to be displayed. This is similar to what Kacmar calls a directive from the OHS to the application [36]. The hypermedia infrastructure will call this routine as needed to display the relevant objects. If the destination of a link traversal is already displayed, the extended widgets automatically handle the event.

5.1.1 Extended Widgets A completely integrated toolkit will have at most one extended widget for each widget present in the user-interface toolkit. These extended widgets behave exactly as the original widgets with the addition of providing access to hypermedia services. As noted above, the

105

Integrated Toolkit

Applications

User-Interface Toolkit

Extended Widgets

Hypermedia Infrastructure

Open Hypermedia System

Figure 5-1. The Conceptual Architecture of the Integrated Toolkit. A line from one box to another signifies the flow of information. Unless indicated by a black arrow, information flows both ways across the line. The gray arrow indicates the potential reuse of user-interface toolkit widgets by the extended widgets.

hypermedia services available for a particular widget will vary depending on the affordances of the widget but will typically include some way to add the widget (i.e. the widget’s anchor) to a link and to initiate a link traversal from the widget. The user-interface to these services for each widget may also vary depending on the affordances of the widget. While it is important to ensure a consistent interface to hypermedia services across widgets, research has shown that only iterative usability testing with end-users will result in a “usable” interface [49]. As such, the definition of a specific interface for each widget is outside the scope of this research. Instead, it is important to note that once defined, these widgets will behave the same in each application providing consistent cross-application access to hypermedia services.

The programmatic interface to an extended widget is virtually identical to the original widget. The difference is limited to initialization of the widget, in which certain hypermediaspecific information is required. Typically, open hypermedia systems require a context in order to persistently store and access hypermedia structures such as anchors and links. Thus, before a hypermedia-enabled widget can create hypermedia structures, the developer must initialize

106 it with context information. The developmental effort of using an extended widget is therefore minimal. There are several techniques which may prove useful to eliminate the need for this context information. These techniques are discussed in Section 7.2.2.

From the standpoint of a toolkit integrator, the work required to create an extended widget consists of identifying the hypermedia services available for a widget, defining a userinterface to those services, constructing a new widget to mimic the original widget (trivial if the toolkit is constructed in an object-oriented language), and extending the new widget to appropriately interact with the hypermedia infrastructure to provide the identified services. The latter includes properly handling the context information supplied at initialization, creating the appropriate hypermedia structures, engaging in the protocols of the hypermedia system, and supplying the end-user with appropriate feedback to hypermedia events, such as link traversal.

While these steps imply a non-trivial amount of work for the toolkit integrator, several characteristics help to make the effort manageable. First, not all widgets need to be integrated for developers to benefit from the extensions. Widgets can be prioritized according to some criterion such as developer requests or perceived utility, and incrementally integrated. Second, widgets are, in general, independent of each other and thus integration work can be done in parallel by a team of toolkit integrators. Third, since the original widgets are unmodified by the construction of the integrated widgets, existing toolkit applications continue to function; no effort is needed to keep the toolkit “backward-compatible.” The result of the integration is

107 a suite of extended widgets that automatically provide hypermedia services in a consistent fashion and utilize common mechanisms provided by the hypermedia infrastructure.

5.1.2 Hypermedia Infrastructure The hypermedia infrastructure provides an interface to the underlying OHS and implements common services for the extended widgets. This is similar to the role played by HyperDisco’s tool integrator [72] which provides this functionality to HyperDisco clients. In the TI technique, however, client applications will primarily interact only with the extended widgets not with the hypermedia infrastructure. The only interaction between them occurs when handling link-traversal directives.

The extended widgets use the OHS interface to access hypermedia services. The interface provides component, anchor, link, and composite operations. These are standard hypermedia concepts [13] in which a component maps to a particular object, anchors specify regions of interest within the object, links specify a relationship of some type over a set of anchors, and composites allow components to be grouped and hierarchically composed. The operations support the creation, deletion, and manipulation of these concepts. In addition, operations are provided to query and search the resulting hyperweb and initiate link traversal. Note that the simple existence of an operation in the infrastructure does not imply each widget will make use of the operation. Instead widgets will use the minimum set of operations needed to implement their hypermedia services.

108 The abstractions provided by the hypermedia infrastructure allow widgets to create hypermedia structures to model their hypermedia needs. For instance, a scrollbar may register itself as a component with one anchor for each of its thumb positions. Traversing to one of its anchors could then cause it to jump to the specified thumb position. A button may be modeled as a component with a single anchor. Traversing to the button’s anchor could then cause the button to execute its action just as if the user had clicked on it. A panel may be modeled as a composite managing a set of components. A user-interface thus creates a set of hypermedia structures within the OHS, allowing it to participate in a hyperweb.

The hypermedia infrastructure also implements the common services required by all of the extended widgets. This prevents having to replicate the services in each widget, provides a consistent behavior across widgets, and localizes the code for them in one place. Common services include managing a connection with the OHS, handling hypermedia-related errors, and providing a consistent interface to link traversals. Initially, the common services use the original toolkit to provide the user feedback. For example, a link traversal dialog may need to make use of window, scrolling list, and button widgets. This use, of course, is not desirable from the standpoint of reuse, since toolkit-specific code is placed in the hypermedia infrastructure. Fortunately, as the toolkit integration progresses, the common services can migrate from using the widgets in the toolkit to using their counterparts in the set of extended widgets. The next section considers other issues related to making the extensions reusable across multiple toolkits and hypermedia systems.

109

Applications

Hypermedia Infrastructure

Integrated Toolkit

User-Interface Toolkit

Abstract Toolkit Interface

Extended Widgets

Common Services Abstract Hypermedia Interface

Open Hypermedia System

Figure 5-2. The Conceptual Architecture Modified to Highlight Reuse Issues. The extended widgets are implemented solely in terms of the abstract toolkit and hypermedia interfaces. This eases the task of reusing the extensions with a different user-interface toolkit or open hypermedia system. The common services of the hypermedia infrastructure initially make use of actual toolkit widgets (gray line) to provide user feedback. Extended widgets are eventually used (black line) as they become available. This bootstrapping process is required for only the initial implementation of the technique since subsequent implementations simply reuse the resulting code.

5.1.3 Plug-and-Play Issues A goal for the TI technique is reusability across the wide range of user-interface toolkits and open hypermedia systems. The technique would have little practical value if applying the technique required the same amount of work the second time as it required the first. In order to address these issues, the conceptual architecture presented in Figure 5-1 has been modified slightly to bring reuse issues to the forefront (see Figure 5-2). The major change is to identify and isolate the areas in which code specific to the user-interface toolkit or OHS is likely to exist. The second change is to indicate the bootstrapping of the hypermedia infrastructure with respect to the widgets used by its common services.

110 The new elements are the abstract toolkit and abstract hypermedia interfaces. These abstract interfaces hide the details of the actual systems used from the extended widgets, which are implemented solely in terms of these new interfaces. Moving to a new hypermedia system or user-interface toolkit involves constructing a mapping between the abstract interface and the actual system used. Once the mapping is complete the extended widgets and the common services can be used without modification. Implementations using an objectoriented programming language can benefit from the use of the Bridge design pattern [21] to aid in the construction of these abstract interfaces.

One design choice used in previous work on providing abstract interfaces to multiple toolkits is the least common denominator approach [66]. This technique hides the differences between user-interface toolkits by providing only the functionality common to all of them. While these issues are relevant to the TI technique, they are not as significant, since the goal is to make the extended widgets as reusable as possible across multiple toolkits. This is different from the goal of making the applications using the extended widgets on one integrated toolkit portable to other integrated toolkits. The interoperability provided by the hypermedia services to the applications reduces the importance of this latter goal. Instead the ability to re-host the extended widgets on a different user-interface toolkit with a minimum of effort is more important. This goal should be achievable since the differences between modern user-interface toolkits are not so significant as to be prohibitive.

111

5.2 Implementation Issues The TI technique has been used to partially integrate two separate user-interface toolkits with the second version of the Chimera open hypermedia system. These prototype implementations have provided some significant lessons associated with the technique and one contribution of this dissertation. The two integrated toolkits are the Java Abstract Windowing Toolkit (AWT) [65] of the Java Development Kit, version 1.0.2, and the subArctic toolkit [34] from the Graphics, Visualization, and Usability Center of the Georgia Institute of Technology. This section continues by describing first the prototype implementations, second the specific contribution provided by them, and third issues surrounding the implementation of the hypermedia infrastructure.

5.2.1 Prototype Implementations The Java AWT is an object-oriented toolkit based on a peer widget mechanism to map the widgets in Java programs into native widgets on a particular operating system/ hardware platform. This has the advantage that the same Java program looks like a native Windows, Macintosh, and Motif application when run in the corresponding environment with no modifications required. The disadvantage is that the AWT is forced into supporting only that functionality which is common to all supported platforms. This is referred to as the lowest common denominator approach [66].

Additional problems with the peer mechanism is that it is difficult to extend the functionality of the existing widgets since the AWT completely depends on the peer widget to notify it as events occur on the widget. If the peer widget handles an event without notifying

112 the toolkit, developers will be unable to override the behavior associated with the event. Developers are thus forced to extend the basic Canvas class and write their own widgets from scratch in order to get the desired functionality. Problems with this solution is that in addition to reinventing the wheel, this process is error-prone, non-standard, and likely incompatible with future incarnations of the AWT. In fact, JavaSoft is currently working on a new userinterface toolkit known as the Java Foundation Classes [65] (which is itself based off of Netscape’s Internet Foundation Classes [48]) which does not depend on the peer mechanism and thus avoids these problems.

subArctic is an advanced object-oriented toolkit written in Java which builds on top of the AWT’s Canvas class to provide state-of-the-art user-interface services such as animation, constraints, semantic lenses (widgets which are meant to float on top of other widgets while displaying some form of information about them), and the separation of widgets from behavior known as interactor styles. The interactor style mechanism is a critical concept which enables the same behavior to be applied to more than one widget. This enables a developer to define the behavior associated with a double click of the mouse, for instance, and then assign that behavior to every widget of an application. This concept appears in other advanced userinterface toolkits such as the interactors of the Amulet user-interface toolkit from CMU [47]. subArctic avoids the pitfalls mentioned above for building on top of the Canvas class since it is a complete and separate toolkit designed from the ground-up as a replacement for the AWT rather than a set of widgets from different developers attempting to work together. subArctic is fully extensible and unlike the AWT provides a fully-articulated event model providing developers with complete control of a widget’s behavior.

113 The work performed on the two implementations of the TI technique has demonstrated that the quality of the integration achieved by the technique is greatly influenced by the presence of the separation of behavior from widget functionality as well as the character of the event model of the target toolkit. For instance, in the integration of the Java AWT, widgets such as the label class can not be integrated with the OHS in any fashion since the AWT delivers no events for a label widget whatsoever. Since the integration must provide at least two operations per widget (Add to Link, and Traverse Link) it requires at least two distinguishable events from the widget to map to these operations. Thus the peer mechanism of the Java AWT hinders the TI Techniques in providing extended widgets which integrate all of the existing widgets of the AWT. This is not true of the subArctic integration. subArctic provides a complete and consistent set of events for all widgets and allows a developer to create new events via interactor styles.

The next level of quality which can be obtained by the technique above the poor quality afforded by the peer widget mechanism is one in which an extensible user-interface toolkit with a fully-articulated event system but without the concept of interactor styles is the target of the integration. In such a toolkit the TI technique could integrate every widget but in order to provide a consistent interface to hypermedia services the required behaviors would have to be reimplemented by every extended widget. (This is not completely true, an objectoriented language with multiple inheritance would allow the behaviors to be implemented as mix-in classes. The developer would only implement the behavior once but code would be generated for each widget utilizing the mix-in.) Thus a complete integration with a consistent user-interface can be achieved with such a toolkit however the developmental effort associated

114 with the task would be high. An example of such a toolkit is any of the many C++ application frameworks shipped with C++ compilers on PC an Macintosh platforms (e.g. PowerPlant by Metrowerks [44]).

The highest level of quality with the least amount of developmental effort is thus obtained by a toolkit such as subArctic or Amulet. Here the behavior for the hypermedia operations are implemented once and assigned to each widget using interactor styles. The subArctic event dispatch subsystem is implemented such that these behaviors can be assigned dynamically at run-time in addition to being statically specified. The toolkit integrator is thus free to focus on extending a complete set of widgets after the behaviors for the hypermedia operations are specified.

5.2.2 Integrated Container Widget The subArctic toolkit provides a flexible container widget which acts as a grouping and hierarchical structuring mechanism over other widgets. Using interactor styles to assign hypermedia operations to the container and Java subclassing to add code to provide feedback in response to hypermedia events it was a fairly easy task to produce an integrated container widget for the subArctic prototype. (An integrated container widget can not be produced for the Java AWT integration since the required events for containers are not provided.) This new container widget associates a single anchor, which acts as a whole-component anchor, with its contents. (An easy extension to this functionality is to associate one anchor with each child widget added to the container.) This enables the container to act as a hypermedia surrogate for any non-aware widget placed within. Note that the user-interface for an entire application can

115 be placed within one of these containers by adding the application’s top level widget to the container (effectively making the integrated container the application’s new top level widget.)

The contribution provided by this technique is that the integrated container offers a rapid way to integrate unaware applications with an open hypermedia system. As will be discussed in Section 6.1, there are several architectures available for use in integrating client applications with open hypermedia systems. Unaware applications which provide no external API can be integrated with the OHS as a launch-only viewer. The OHS can invoke the application and cause it to display a document but at that point the application provides no further hypermedia capabilities. The effort to integrate a launch-only application is minimal. The OHS must be configured with the information necessary to invoke the application and an intermediary (typically an integrated application with a command line interface) can be used to register hypermedia structures leading to the documents viewed by the launch-only application. The integrated container widget offers a technique which has a comparable developmental effort (it takes on average ten lines of code to re-parent an application with an integrated container and add the appropriate toolkit initialization code) yet provides a default level of hypermedia services such as the ability to send and receive link traversals and to add the whole-component anchor to new links. As discussed in Section 6.2, one Chimera 2.0 client has demonstrated the benefits of this technique.

5.2.3 Implementation of the Hypermedia Infrastructure The hypermedia infrastructure can be implemented in one of two ways. The first approach is to build its services into the toolkit code which gets linked into each toolkit-

116 constructed application. This has the advantage that communication between the extended widgets and the infrastructure occurs locally with no intervening process hops required by inter-process communication. The disadvantage is that when a user runs multiple toolkitconstructed applications the code for the hypermedia infrastructure is loaded separately for each application and there is no easy way to inform each instance of the hypermedia infrastructure about the existence of the others and no way to synchronize the services provided by these infrastructures. Thus, in the Java AWT integration where this approach was used, if two separate toolkit-constructed applications are invoked and the connection to the Chimera server fails (perhaps because the desired Chimera server is not active or incorrectly specified) then two identical dialogs created by the two instances of the hypermedia infrastructure appear to the user informing him of the failure. This approach is thus annoying to the end-user and non-scalable.

The second approach, explored in the subArctic integration, is to implement the hypermedia infrastructure as a separate server and to place an API for the infrastructure in with the code that gets linked with each toolkit-constructed application. The hypermedia infrastructure is now a server which runs locally within the user’s LAN which implements the common services described in Section 5.1.2 for all of the user’s toolkit-constructed applications. The extended widgets automatically implement the protocol associated with the hypermedia infrastructure and thus toolkit application developers never have to concern themselves with hypermedia issues directly (although access to the API is provided in case the developer desires to customize the behavior of the services for his application). The user does not even have to invoke the hypermedia infrastructure server directly since code is placed

117 within the extended widgets to invoke the infrastructure if it is not available during toolkit initialization. This approach is much more scalable than the former approach with the only disadvantage being the process hop which is now required for the extended widgets and the infrastructure to communicate. However, since the hypermedia infrastructure server will always be running locally inter-process communication performance should be acceptable.

CHAPTER 6: Validation

The overall goal of this dissertation is the provision of pervasive hypermedia services throughout modern computing environments. I have argued that open hypermedia systems and a suite of integration techniques is the best means of realizing this goal. In order to explore these ideas, I developed the Chimera open hypermedia system and a novel integration technique. Chimera is an advanced, robust, open hypermedia system with a flexible set of hypermedia concepts, a powerful API, and a scalable, distributed architecture capable of supporting a diverse range of clients and media types. The TI technique defines a modular, robust, integration architecture which enables a large-scale systematic approach to providing hypermedia services consistently and pervasively to client applications. In particular, the integrated user-interface toolkit acts as a harness for all of its client applications transforming each one into a participant of the underlying open hypermedia system. The claims of this dissertation can be validated by examining the characteristics of the existing clients of the Chimera OHS and the prototypes of the TI technique. While this set of clients is small, taken in sum, they demonstrate and validate the contributions of this dissertation.

This chapter is organized as follows. A framework for modeling client integrations is presented, followed by a description of Chimera’s integrated clients. A matrix is then presented demonstrating the coverage these clients provide over the framework and the contributions of this work.

The contributions of this dissertation, as discussed in the Introduction, are:

118

119 1. Support for Heterogeneity 2. Views as First-Class Objects 3. Viewer-Client Distinction and Multiple APIs 4. Integration with the WWW 5. User-Interface Toolkit Integration Technique 6. Integrated Container Widget as Whole-Component Anchor

The matrix will lend validation to all of these contributions. Contribution 1 is directly supported by contributions 2 and 3. I also present the impact my research has had on the Hypermedia community after the presentation of the matrix.

6.1 Client Integration Framework Whitehead presents a modeling framework for client integrations in [67]. The framework elements consist of artists, communicators, and containers. Artist is a generic term for code which manipulates a particular class of object. The three categories of artist are anchor, link, and native. The latter displays and manipulates application-specific objects. Communicators facilitate information flow between applications and the open hypermedia system. Finally, containers are used to create groups of the previous elements. A particularly important type of container is a communications translator. A communications translator typically contains two communicators and code which translates between the two protocols supported by the communicators.

This simple model can then be used to characterize applications prior to an integration as well as to characterize the elements of a complete integration. These two

120 abilities are important since the model can be used to guide an integration by comparing the initial state of an application with the target state of a complete integration. Any missing pieces must be supplied by the integrator in order to achieve a complete integration. The important aspects of an application’s initial state are the existence (or non-existence) of an anchor and link artist and its communication status. With respect to the latter, an application can be non-communicative if it has no mechanisms for communicating with external applications, non-native if it provides communication mechanisms not employed by the target OHS, and native if it utilizes a communicator specific to the target OHS. These aspects can then be compared with the elements of a complete integration which include:

1. the presence of all three artist categories, 2. a communicator for the target OHS, 3. and a communications translator if the target application is non-native.

In a nutshell, a complete integration requires a communication path between the application and the OHS and the ability to manipulate anchors, links, and the application’s native objects. Hand in hand with these modeling capabilities, the framework defines three types of integration architectures: launch-only, wrapper, and custom. In addition, some integrations employ aspects of more than one of these architectures resulting in a combination architecture.

A launch-only architecture involves launching a non-communicative application to display an object which none of the other OHS clients can display. The main requirement of a launch-only application is the ability to specify the name of a file to open. There is no need

121 for an anchor artist since the assumption is that the anchor refers to the entire document being displayed by the launch-only application. Since the application is non-communicative no link operations can be initiated from within the application. Instead, if the application can respond to requests to display additional documents, link traversals to the application’s documents can be simulated by requesting it to display the destination document. These applications typically require an intermediary to create the links which invoke the launch-only application in the first place. In standard Web browsers, this is accomplished by mapping document MIME types to specific launch-only applications. In HyperDisco [72], the integrated Emacs client has an operation which allows it to register the documents of launchonly applications which, in turn, enables them to be included in links.

A wrapper architecture uses a separate computational entity which facilitates interaction between the target application and the OHS. This entity, or wrapper, can be implemented as a separate operating system process or may be loaded into the target application via a plug-in mechanism or similar. There are two styles of wrapper architecture. The first style employs only a communications translator which utilizes the hypermediarelated abilities of the application’s communicator to implement event handlers for the OHS’s hypermedia events. In addition, it converts the application’s event notifications into operations on the OHS’s API. In this instance, the link and anchor artists are assumed to be in the target application or some other application used concurrently with the target application. The second style of wrapper contains, in addition to a communications translator, one or both of the anchor and link artists. These supplied artists typically use applicationindependent means of performing their work such as supplying a menu for the application to

122 include in its menu-bar. A wrapper architecture is best employed for integrating applications whose source code is inaccessible and who provide some form of external API.

Finally, a custom architecture is one in which either access to the target application’s source code is available or the application provides an internal customization language similar to Emacs Lisp or Microsoft’s Visual Basic. These applications are typically modified to add anchor and link artist capabilities and include support for the OHS’s native communications protocol. Since the integrator has a high-level of control over the application, a custom architecture typically provides sophisticated hypermedia services.

In terms of developmental effort, custom integrations are typically the most complex integrations to perform. A key factor in complexity is the presence of an anchor artist. Since this is non-trivial code to implement (since anchors are typically tailored to the display of the application’s native objects), the absence of this artist can entail a large amount of work supplying the necessary hooks into the application in order to enable anchor functionality [67]. The launch-only architecture involves very little developmental effort after the mechanisms for specifying a launch-only application are in place. The only potential modification is adding a mechanism to the application to specify the name of the file it is to open on launch. Finally, the wrapper architecture can run the gamut of developmental complexity from simple to complex depending on the number of architectural elements present in the initial application and the number of elements the wrapper provides.

123 The TI technique can be considered a variant of the custom integration architecture. However, in contrast, the TI technique greatly reduces the developmental complexity associated with this style of integration. Developers must still make source-code modifications to their clients to make use of the integrated user-interface toolkit. However, these modifications are limited to a few initialization details and the inclusion of hypermediaenabled widgets. Once these obligations have been met, the widgets provide anchor artist capabilities and the toolkit’s hypermedia infrastructure provides a communications link to the target hypermedia system and link artist capabilities. This greatly reduces the work required by the application developer since the integrated toolkit provides all of the elements of a complete integration except the native artist. Since the native artist is presumably a part of the application already, this variant of the custom-style integration architecture requires very little work indeed.

In the next section, the modeling framework is used as a vehicle for describing the set of clients integrated with Chimera. This discussion is then used as a basis for creating a matrix which summarizes these clients coverage of the framework presented here and their ability to validate the contributions of this dissertation.

6.2 Integrated Chimera Clients Chimera has a large set of integrated clients. A majority of these clients were integrated by teams of undergraduates as part of their projects for a senior-level software engineering class. The fact that a majority of Chimera’s clients were integrated in less than ten weeks by four-person teams with intermediate programming skills scopes the work involved

124 with an integration. While a custom integration of high quality providing a large set of hypermedia services is a non-trial task, a substantially simpler task is integrating a client to the point of providing the basic services of anchor manipulation (creation, deletion, and inclusion) and link traversal initiation. In fact these basic services require at most eight operations form the Chimera API including create_viewer, create_object, create_view, create_anchor, delete_anchor, get_anchors, add_anchor_to_active_link and traverse_links. In addition, a client must implement four event handlers for Chimera’s active_site, active_web, active_link, and link_traversal events. This small set of operations and events lends weight to Whitehead’s assertion that the real complexity of a client integration depends on the state of a client’s anchor display capabilities [67]. Chimera has integrated the following clients: FrameMaker 3.1, Chimera Shell, XEmacs, Xvi, XGif, xmpeg, sound player, flight simulator, Chimera presence applet, and example clients included with the subArctic user-interface toolkit.

6.2.1 FrameMaker 3.1 FrameMaker is a document processing system which aids in the generation of complex documents. It has an RPC-based API and contains an internal hypertext system which allows FrameMaker documents to become read-only on-line presentations. From the standpoint of the integration framework, FrameMaker is a non-native application with built in anchor and link artists. A wrapper-style architecture was used to integrate it since access to source code was not available (it is a commercial product) and an external API was available. The wrapper was implemented as a separate operating system process written in Ada. It translated between Chimera’s Ada API and FrameMaker’s RPC-based API. FrameMaker’s API

125 provided operations to open and close documents and to jump to FrameMaker hypertext markers. FrameMaker’s hypertext model was mapped to Chimera’s model in the following manner. FrameMaker itself was registered as a viewer by the FrameMaker wrapper. Each document was registered as an object with the complete path of the document stored as the object’s name. Each document displayed by FrameMaker was mapped to a Chimera view. Each hypertext marker within the document was mapped to a Chimera anchor. This mapping was achieved by storing Chimera’s anchor ids as text strings within FrameMaker’s hypertext markers. FrameMaker links were not used. Instead, the mapped anchors were included in Chimera’s links which are stored separately.

The FrameMaker integration demonstrated the ability to integrate unmodified binary applications with Chimera. The hypermedia services provided by the integration were anchor creation and inclusion and initiating and handling link traversals. These services were impacted by various restrictions imposed by FrameMaker. Hypertext Markers have the scope of a FrameMaker paragraph. Thus anchors could only have a granularity of a paragraph. Plus anchors could only be created while the document was in an editable mode. Anchor inclusion and link traversal could only occur when a document was in a read-only mode. This required a user to keep track of the current mode and forced the user to learn how to switch between modes which was accomplished via a non-intuitive key sequences. These difficulties is an example of the issues encountered in creating an integration using a wrapper architecture. Since complete control of the application is not possible, the quality of the final integration is determined by the range and depth of the abilities and restrictions imposed by the target application.

126 6.2.2 Chimera Shell The Chimera Shell is a native application with anchor and link artists. This client provides a command-line interface to the Chimera 1.0 server. The user can manipulate the state of the hyperweb by issuing commands which correspond to operations defined by Chimera’s C API. The Chimera Shell is not a typical Chimera client in that it does not register any Chimera concepts with the server for itself. Instead it can be used to register documents for launch-only viewers similar to HyperDisco’s Emacs client, quickly browse the contents of a hyperweb or act as a wrapper for some other application. This client demonstrates the versatility and power of the Chimera API. The same interface that services client’s hypermedia requests can also be used by utility programs for a variety of tasks.

6.2.3 XEmacs XEmacs is a popular X windows-based variant of the Emacs text editor. It is a nonnative application with an internal customization language. It also has features related to text selection that form the basis of an anchor artist. One communication mechanism XEmacs provides is the ability to transfer messages back and forth to a captive process. Essentially XEmacs invokes a sub-process and redirects its standard-in and standard-out channels to buffers that XEmacs controls. With this as a basis, a combination architecture was chosen to integrate XEmacs with Chimera 1.0.

First, the Chimera Shell was chosen as a wrapper for the XEmacs client. Using the communication mechanism described above, XEmacs could issue Chimera commands to the Chimera Shell which translates them into operations on the C API. Asynchronous

127 hypermedia events appear on the Chimera Shell application’s standard-out channel which XEmacs is monitoring. When an event is received, XEmacs is configured to invoke an event handler to process the event. Second, the customization language was used to implement an anchor artist, a link artist, and a set of event handlers. The anchor artist was responsible for displaying anchors as underlined text within a file. The link artist was realized as a Chimera menu in the XEmacs menu bar which housed Chimera-related operations. Chimera’s hypermedia concepts were mapped into XEmacs similar to their use in the FrameMaker integration. The only difference being that an anchor’s location was stored as an attribute on the anchor concept which represents the anchor within Chimera.

XEmac’s customization language enabled a high-quality integration typical of customstyle architectures. In particular its user-interface control features and its ability to participate in external communication protocols afford a high degree of a control over the application. This control, in turn, made possible the deep integration of hypermedia services into its core task of editing text documents. Thus the mere presence of a customization language is not sufficient to ensure a high-quality integration. More critical are the areas of control the language affords within the host application.

6.2.4 Xvi Xvi is an X windows-based version of the vi text editor. It is a non-communicative application with text-selection capabilities which form the basis of an anchor artist. Since source code was available, a custom integration was performed. The source code was modified to make direct calls on Chimera’s C API, implement event handlers, and provide anchor and

128 link artist functionality. The anchor artist portrayed anchors as regions of underlined text. Chimera-related operations could be invoked using vi’s command line or by use of a “Chimera control panel” which was essentially a menu of Chimera commands presented in a separate X window. Chimera hypermedia concepts were mapped into Xvi’s domain in the same fashion as the mapping performed for the XEmacs client. These similar mappings gave rise to the new feature in Chimera 2.0 which supports view-independent anchors. Having text editors use the same mappings enables them to read and write the anchors created by some other text editor.

6.2.5 XGif XGif is a viewer for GIF images. It is a non-communicative application with no anchor or link artist functionality. A custom integration was performed since XGif ’s source code is freely available. Similar to the Xvi integration, support for the Chimera C API, a set of event handlers and both an anchor and link artist was added to the original application. Anchor and link operations are made available in a control panel similar to the one used in the Xvi integration. XGif uses a straightforward mapping of Chimera’s hypermedia concepts. XGif is registered as a viewer, and each image is registered as an object with the object’s name specifying the complete path to the image’s location within the file system. A view is mapped to the actual display of an image. Anchors are displayed as rectangles on the image. The original image is left unmodified, however. Instead, the location and size of the rectangles are stored as attributes on anchors associated with the image’s view. When an image is loaded, XGif requests all anchors associated with its view, and uses the attribute information to

129 recreate the rectangles dynamically. In Chimera 2.0, this mapping is being used as a basis for view-independent anchors over any image type.

6.2.6 Xmpeg Xmpeg is a viewer for MPEG movies. It is a non-communicative application with no anchor or link artist functionality. A custom integration was performed since Xmpeg’s source code is freely available. Support for the Chimera C API, a set of event handlers, sophisticated anchor artist and minimal link artist functionality was added to the original application. The application could include its anchors in links but depended on an external link editor (a service provided by a utility program in Chimera 1.0 and by the Chimera server in Chimera 2.0) for all other link-related operations.

The most notable aspect of this integrated client was the advanced functionality provided by its anchor artist. Anchors appeared as rectangles on the movie. Each rectangle has in addition to its size and location attributes a start-frame and end-frame attribute. The size and location attributes are allowed to vary over each frame. Thus the integrated client gave the user the ability to select an object of interest within the movie and then modify the anchor so that it moved and changed shape in order to track the object’s progress throughout the movie. A running clip could have multiple anchors active at a time and a link traversal could be initiated from any of them during the playing of the movie.

130 6.2.7 Sound Player The sound player application was written from the ground-up to be a Chimera client. It is thus a native application with built-in anchor functionality. Like the Xmpeg client, it largely depends on an external link editor for link-related operations. The sound player presented a scrolling list of sound names. Selecting a name from the list caused the corresponding sound to be played. Each entry in the list was registered as a separate Chimera view. The view’s object stored the name of the sound. The sound player was registered as the viewer. A dummy anchor was created on each view so that the sounds could be included in links. Whenever a link traversal event is received, the sound player traversed the concepts from anchor to view to object to sound name. It then played the corresponding sound. The principle distinction of the sound player is that it is the client of three separate systems. Chimera provides hypermedia services, Chiron [66] provided user-interface services, and a sound server took care of actually playing the indicated sounds. This architecture demonstrates how Chimera can support multiple client architectures. This support is enabled, in part, by its separation of viewers and clients. By making clear the duties of a client, all other aspects of a client are left-unspecified and can thus vary widely.

6.2.8 Flight Simulator The flight simulator is a multi-threaded simulation of aircraft flight mechanics written in Ada. It is a non-communicative application with minimal anchor artist and no link artist capabilities. A custom integration was performed adding support for Chimera’s Ada API, implementing a set of event handlers, and adding a menu to each gauge to provide minimal anchor and link artist capabilities. Additional link-related capabilities were provided by an

131 external link editor. This integration took advantage of Chimera’s distinct separation between the notions of clients and viewers to implement each gauge of the flight simulator as a separate viewer. Code was added to implement the responsibilities of a client and this code was responsible for managing access to the Ada API and routine hypermedia events to the proper viewers.

The mapping of Chimera’s hypermedia concepts into the flight simulator’s domain raised some interesting issues. Some of the gauges displayed information based off of more than one variable of the flight simulation. In Chimera 1.0, support for this style of view was unsatisfactory. Typically, an object was created which represented the combination of two or more objects. This combination object was then used to create an instance of a view. The objects referred to by this combination object were either stored as attributes on the combination object instance or took the form of implicit knowledge by the application’s developer. Motivated by this example, Chimera 2.0 provides direct support for this style of view with the use of composite objects. A combination object can now be created and have its sub-objects directly added to it. This makes the relationship between the combination object and its sub-objects explicit. These relationships can now be exploited by other applications such as hyperweb visualization tools.

6.2.9 Chimera Presence Applet The Chimera presence applet is the first client to demonstrate Chimera’s integration with WWW mechanisms. It is a native application with both anchor and link artists and support for Chimera’s Java API. Its primary purpose is to provide Chimera’s hypermedia

132 services to users from within a standard WWW browser. Each HTML page is mapped into a Chimera view. The view acts as a whole-component anchor, thus there is no support for creating anchors within the content of the HTML page. The whole-component anchor can be added to Chimera links however enabling link traversals between the WWW and the Chimera clients within a user’s environment.

A deep integration with the WWW is required to enable this applets functionality. First, Java restricts an applet from learning the identity of its users. Thus an HTML form is used to query for this information before the applet appears. An HTTP cookie is used to make this information persist. A CGI script enables the inclusion of the applet into an HTML page without modifying the original HTML document. The CGI takes the destination URL specified by the user, retrieves the associated document, adds the applet at the end of the document and converts all URLs in the document to point back at the CGI script. In this fashion, as the user clicks on the links contained within the document, the CGI script is invoked again allowing the applet to be included in the destination document. This provides the feeling that the applet is traveling through the Web with the user. Chimera 2.0’s architecture directly supports Java applet clients by providing a Chimera server on the machine from which the applet was downloaded to handle the requests of the applet and avoid certain security restrictions imposed on applets.

6.2.10 Mail Client Demo The subArctic user-interface toolkit from Georgia Tech. comes with a demonstration of an electronic mail client. The application is not fully-functional however, since its primary

133 purpose is to demonstrate advanced features of the subArctic toolkit. It is however close enough to a real application to demonstrate the non-intrusive nature of the TI technique. The mail client, from the standpoint of the modeling framework, is a non-communicative application with no anchor or link artists. The client was modified to place its user-interface within a hypermedia-aware container widget provided by the TI technique’s integration of the subArctic toolkit with Chimera 2.0.

The integrated container widget acts as a whole-component anchor for the mail client demo. It registers an anchor for the mail client which can be included in any Chimera 2.0 link. While no hypermedia services are provided within the internals of its interface, the mail client was essentially transformed into a Launch-Only viewer by the integrated container. However, unlike typical Launch-Only integrations, the integrated container widget has the ability to initiate link traversals.The integration occurred in less than half an hour and required the addition of less than twenty lines of code. The majority of the half hour was spent understanding the structure of the mail client’s code and determining the best location for the simple modifications.

6.2.11 Spreadsheet Demo Another example client for the subArctic toolkit is a fully-functional spreadsheet client. As with the previous client, this application is non-communicative with no anchor or link artists. The integrated subArctic toolkit replaced the labels used to denote the columns and rows of the spreadsheet with hypermedia-aware labels. This enabled anchors to be associated with each row and column of the spreadsheet. The integration occurred in less than

134 half an hour and required the addition of less than twenty lines of code. The major change to the application occurred in the initialization code required by the integrated toolkit and supplying a value for the additional parameter (an object name) required by the hypermediaaware label’s constructor.

6.3 Validation Matrix The validation matrix is split into three parts and summarizes the issues discussed in the client descriptions above (See Table 6-1, Table 6-2, and Table 6-3). Each column presents information about a particular client. A row contains information about a client with respect to a particular integration architecture or to a particular contribution of this dissertation. A client is not expected to have information in each row; the range of categories covered by the rows is diverse to the point that such a client would be an anomaly. However, when taken in total, each row of the table should be covered by at least one client.

In fact this is not the case. The one row not covered by any of these clients is the Launch-Only integration architecture. However, it is not the case that Chimera is incapable of supporting this style of architecture. As noted in the client descriptions above, the Chimera Shell can be used as an intermediary for non-communicative applications, registering the hypermedia concepts necessary to include their documents in links. After this has been accomplished, all that is necessary is for the process invoker to be configured properly for the application as needed. Launch-Only architectures were not explored in Chimera despite being a rapid integration strategy for applications since they provide no hypermedia services.This

135 Table 6-1. Coverage and Validation Matrix Based on Chimera’s Clients (Part 1) FrameMaker

Chimera Shell

XEmacs

Xvi

Launch-Only

N/A

N/A

N/A

N/A

Wrapper

Ada wrapper utilized FrameMaker’s external API.

N/A

Chimera Shell used as wrapper

N/A

Custom

N/A

New application written to provide command-line interface to Chimera.

Emacs code used to communicate with Chimera Shell and to provide anchor and link artists.

Source code modified to include anchor and link artists and support for Chimera API.

Combination

N/A

N/A

Combination of Wrapper and Custom

N/A

Use of Views

Views mapped into the display of a FrameMaker document.

Created no display but could be used to generate views for other applications.

Display of text documents corresponded to Chimera views.

Display of text documents corresponded to Chimera views.

Viewer-Client Distinction

N/A

N/A

N/A

N/A

Multiple APIs

Ada API

C API

C API (via Chimera Shell)

C API

Integration with the WWW

N/A

N/A

N/A

N/A

Use of the TI Technique

N/A

N/A

N/A

N/A

Integrated Container as WholeComponent Anchor

N/A

N/A

N/A

N/A

style of integration architecture was thus at odds with other research priorities during the development of Chimera 1.0 and Chimera 2.0.

136 Table 6-2. Coverage and Validation Matrix Based on Chimera’s Clients (Part 2) XGif

Xmpeg

Sound Player

Flight Simulator

Launch-Only

N/A

N/A

N/A

N/A

Wrapper

N/A

N/A

N/A

N/A

Custom

Source code modified to include anchor and link artists and support for Chimera API.

Source code modified to include support for anchor artist and Chimera API. (Link artist support provided mainly by Chimera linkeditor.)

Native application with support for both anchor artist and Chimera API. (Link artist support provided mainly by Chimera linkeditor.)

Source code modified to include support for anchor artists and Chimera API. (Link artist support provided mainly by Chimera linkeditor.)

Combination

N/A

N/A

N/A

N/A

Use of Views

Display of GIF images mapped to Chimera views.

Display of MPEG documents mapped to views.

Sound Names in scrolling list mapped to views.

Each gauge represented distinct Chimera view. One view represented synthesis of two underlying objects.

Viewer-Client Distinction

N/A

N/A

Sound player was the client of three separate servers. Chimera’s minimal requirements on client architectures enables support for non-traditional client architectures.

Flight simulator had six separate viewers running under a single client.

Multiple APIs

C API

C API

Ada API

Ada API

Integration with the WWW

N/A

N/A

N/A

N/A

Use of the TI Technique

N/A

N/A

N/A

N/A

Integrated Container as Whole-Component Anchor

N/A

N/A

N/A

N/A

The integrated clients cover the rest of the issue space addressed by the matrix. Of the eleven clients, seven clients employed custom integrations, two made use of the TI technique, one utilized a wrapper architecture, and one applied a combination integration of the wrapper

137 Table 6-3. Coverage and Validation Matrix Based on Chimera’s Clients (Part 3) Chimera Presence Applet

Mail Client Demo

Spreadsheet Demo

Launch-Only

N/A

N/A

N/A

Wrapper

N/A

N/A

N/A

Custom

New application written to support Chimera from ground up. Provides anchor and link artists and support for Chimera API.

N/A

N/A

Combination

N/A

N/A

N/A

Use of Views

Each HTML page mapped to a separate Chimera view.

The integrated container widget associates a view with its contents.

A view was associated with each label of the spreadsheet.

Viewer-Client Distinction

N/A

N/A

N/A

Multiple APIs

Java API

Java API

Java API

Integration with the WWW

Multiple Web mechanisms used to enable client including Java applets, cgi-scripts, and HTTP cookies.

This subArctic demo is implemented as an applet. Both applets and applications are supported by the integrated toolkit.

This subArctic demo is implemented as an applet.

Use of the TI Technique

N/A

Use of container widget rapidly integrated the entire user-interface of the mail client.

Use of integrated label widgets quickly provided hypermedia services over the rows and columns of the spreadsheet.

Integrated Container as Whole-Component Anchor

N/A

Produced LaunchOnly Viewer augmented with link traversal services

N/A

and custom architectures. A majority of the custom integrations added both anchor and link artist capabilities to the target application. Three however avoided the additional effort of a link artist and depended on an external application to provide services such as creating and naming links and selecting a link to become active. This latter technique is employed by the

138 TI technique integrations, in which these services are provided by the common services of the integrated toolkit’s hypermedia infrastructure. The wrapper architecture succeeded in providing external hypermedia services to FrameMaker, but the quality of the services was impacted by restrictions imposed by FrameMaker’s API and internal hypertext mechanism. These problem were avoided in the combination architecture of the XEmacs client since its customization language provided the ability to implement custom anchor and link artists which provided high-quality hypermedia services.

The integrations made use of all three implementations of Chimera’s API demonstrating that multiple APIs enable a diverse range of clients to have access to hypermedia services. The flight simulator explored the power of the separation of the concepts of viewer and client provided by Chimera. In particular, it enabled a multi-threaded client like the flight simulator to be effortlessly modeled and integrated into the hypermedia system. The set of client architectures ranged from single-threaded X windows applications written in C to Java applets to multi-threaded Ada applications. The minimal set of requirements placed on clients enable this diversity. In addition, they enable the sound player to take advantage of hypermedia services while also being the client of two other systems. The use of views demonstrates the flexibility of this powerful hypermedia concept. Views were able to model displays ranging from the altitude gauge of a flight simulator to names in a scrolling list to GIF images, and MPEG movies. The abstraction afforded by this concept is Chimera’s direct means of support for the heterogeneity of modern computing environments. Integration with the WWW was demonstrated by the support for Java applets, and the coordination of a variety of Web mechanisms in order to implement the Chimera presence applet. The TI

139 Technique demonstrated its power with the integration of two separate clients in under one hour. The similarity of the hypermedia-aware labels to their original counterparts made it simple to plug them in to the spreadsheet application. The integrated container can rapidly integrate any subArctic application and provide it with more services than possible with a Launch-Only with comparable developmental effort.

This complete coverage of both integration architectures and a demonstration of the benefits afforded by the contributions of this dissertation support and validate the claims made by this dissertation.

6.4 Impact on Community An additional validation of my research lies in the impact it has had on the Hypermedia community as a whole, and the Open Hypermedia Systems community in particular. The techniques behind Chimera and the TI Technique have influenced researchers and instigated comments, feedback, and the exchange of ideas.

Chimera was informally presented to the Hypermedia field as a demonstration at the 1993 ACM Conference on Hypertext in Seattle Washington. This demo introduced Chimera’s developers to other hypermedia researchers and paved the way for increased interaction in the community. A paper on Chimera 1.0 appeared in the 1994 proceedings of the European Conference on Hypermedia Technology [2]. This paper formally introduced Chimera to the Hypermedia community and, in particular, highlighted the importance of the view as a hypermedia concept. On the basis of this paper and its presentation, Hugh Davis

140 informally notified me that the Microcosm group would like to “nick” the view concept and explore its use within the Microcosm OHS. In response, the Microcosm group presented a poster session at the 1996 ACM Conference on Hypertext (Hypertext’96) about their work with views. More recently, Uffe K. Wiil in [75] notes that HyperDisco has a construct similar to views however it does not have the status of a first-class concept as it does in Chimera.

At Hypertext’96, Chimera-related research was presented at two workshops: The Second International Workshop on Open Hypermedia Systems [73] and the Second International Workshop on Incorporating Hypertext Functionality Into Software Systems. The former dealt with Chimera’s future plans for supporting versioning of hypermedia structures, while the latter presented a preliminary version of the TI Technique. A paper describing the complete TI Technique [4] was presented at the Thirtieth Annual Hawaii International Conference on System Sciences. Two Chimera-related papers were presented at the 1997 ACM Conference on Hypertext; One paper describes the work which lead to the development of Chimera 2.0 [5], the other presents the client integration framework discussed above [67]. In addition, I actively participated in the Third International Workshop on Open Hypermedia Systems [74].

CHAPTER 7: Future Work

The research of this dissertation has made significant contributions in the field of open hypermedia systems. However, open issues remain with the work overall, and the toolkit integration technique may be useful in other fields. These research questions are considered in this section and my plans for future work are discussed.

7.1 Open Issues in Open Hypermedia Systems My work in open hypermedia systems has produced two systems which explored techniques for supporting heterogeneity and integrating with the WWW. Future work will include improving the functionality provided by these systems to enable in-field evaluation of their associated techniques. Chimera 2.0 addresses several major problems with Chimera 1.0 including lack of link traversal semantics, no support for distribution of hyperwebs, no links between hyperwebs, and non-standard user-interface interaction styles. However, Chimera 2.0 is, relative to Chimera 1.0, still in its infancy. Several features and issues explored in Chimera 1.0 such as multi-lingual APIs, a large set of integrated clients, and filtering anchors and links based on ownership, are not yet a part of Chimera 2.0. These deficiencies are not a result of any fundamental aspect of Chimera 2.0’s architecture but rather occur because of their relatively low priority with respect to Chimera 2.0’s major research goals. These features will be added as Chimera 2.0 matures.

More important are Chimera 2.0’s open research questions. These include completely exposing the APIs to Chimera’s servers via HTTP, exploring the features enabled by having

141

142 servers of the same type communicating directly with one another, offering higher quality services to clients which integrate deeply with the web, and improving the WWW via Chimera’s services.

7.1.1 Exposing Server APIs Chimera 2.0’s servers have the ability to receive and process HTTP requests. Currently, only the GET method of HTTP is supported, and only a small set of URLs is implemented. However, a fair amount of power was gained despite the minimal implementation. All servers are configured to generate an informational response to their root URL. While this response is human-readable, its primary reason for existence is to be indexed by Internet search engines. This indexing, in turn, enables users to search for Chimera 2.0 websites using a standard Web mechanism. Another feature enabled by HTTP support is the lightweight connection protocol employed by the Chimera 2.0 servers. When the Chimera server connects to the hyperweb server, it first sends an HTTP request to the hyperweb manager. This request serves several purposes. First, HTTP is a relatively light-weight protocol. If the hyperweb manager does not respond to the request, i.e. the request fails, the Chimera server is notified rapidly and few computing resources were expended. Second, If the URL specifies the target hyperweb, the hyperweb manager can verify the existence of the hyperweb before returning the hyperweb server’s connection information. If some error has occurred and the hyperweb, in fact, does not exist, the response to the HTTP request prevents utilizing computing resources to connect to the hyperweb server with Chimera’s more heavyweight protocol. Finally, if the hyperweb indeed exists, then the connection information is returned rapidly in a formatted text string. The Chimera server can then quickly parse this

143 information and establish a connection to the hyperweb server. An additional feature of HTTP support is the ability to request and receive status information about a server from within a standard Web browser. This aides developers while debugging but can also be useful for end-users maintaining the system or trying to isolate problems encountered during system use.

Two avenues of future research in this area are exploring the use of other HTTP methods and exposing the full Chimera API via HTTP. With respect to the former, the advantages of using HTTP methods other than GET must be explored. PUT for instance might be used to facilitate information exchange between two servers of the same type. POST can be used to simplify the information contained in the URLs sent to Chimera while slightly increasing complexity in a client implementation. (POST methods are an alternative form of the GET method in which parameters to a URL are removed from the URL proper and included in the HTTP request by the client after sending the stripped-down URL.) In addition, the possibility of defining new HTTP methods for use with Chimera should not be overlooked. The trade-off here is between efficiency and standardization. New methods will likely be adopted slowly by Web applications however a Chimera-specific method might replace multiple GET/POST requests. These issues will be addressed concurrently while developing the HTTP interface to Chimera’s services.

The idea of accessing the full range of Chimera’s hypermedia services via HTTP is primarily motivated by interoperability. A prodigious amount of software is being developed with support for the HTTP standard. Once the basic support for sending and receiving

144 HTTP requests is implemented, a system can quickly interoperate with some other system by including support for the target system’s URLs. Some URLs may be stand-alone requests for information; others may have to be used in a particular order. Thus, a protocol may have to be implemented in order to fully interoperate with the target system. The costs of this form of interoperability are relatively low since libraries which implement the HTTP protocol are available in a variety of programming languages from the W3C [76] and other organizations. These reference implementations allow support for the HTTP protocol to be rapidly included in an application leaving the real work focused on supporting a system’s URLs to achieve interoperability.

In particular, applications which access Chimera’s URLs can gain access to hypermedia services without having to use the standard Chimera API. In addition, the HTTP interface can serve as a temporary API for applications written in a programming language for which a Chimera API implementation is not available. While the Chimera server is naturally a target of this technique, exposing the hyperweb manager’s API via HTTP will also produce benefits. In particular, it will allow remote clients to manipulate the hyperwebs on a particular site (provided the client has been authenticated and has permission to manipulate the hyperwebs in the first place).

In order to support full Chimera clients via an HTTP interface, the use of HTTP’s cookie mechanism may be required. There is a trade-off to be explored here in terms of human ease-of-use and requirements placed on Chimera clients. Cookies are a means of supplying state information on top of HTTP’s stateless protocol. A typical interaction occurs

145 as follows: a client sends an HTTP request to the server which returns a response containing a cookie. It is now the client’s responsibility to return the cookie with all subsequent HTTP requests to the server. The server can then store information in the cookie that must persist between HTTP requests. For the Chimera server this information consists of a user’s name and a client identifier. This information allows the server to track which client is making a request. The trade-off is that client support for the cookie mechanism is non-trivial. Cookies are associated with particular URL domains and the client has to track which cookies get sent on any given request. On top of this, each cookie has a lifetime associated with it and the client must ensure that the cookie stays persistent until its lifetime has expired. This implies that if the client ceases execution with cookies still active, it must store these cookies persistently in some fashion in order to make them active again on a subsequent invocation. The benefit to the cookie mechanism is that the user can enter easy to understand URLs within a standard Web browser which access Chimera servers and have the Web browser’s built-in cookie mechanism take care of any cookies required to support the Chimera protocol. The alternative to the cookie mechanism is to place all persistent information in the URL itself as parameters. This can lead to long, hard-to-remember URLs which users will want to avoid entering by hand. Plus this alternative does not allow the server to change the value of the cookies over time. Instead, if a change is desired, it must indicate this in some fashion within its output and then depend on the user or client to parse this indication and use the new value on subsequent requests. Future work will explore these pros and cons in greater detail.

146 An additional research issue is supporting Chimera’s event notification services via HTTP. Currently, the Web has no notification service, thus clients which use the HTTP interface will be unable to receive Chimera’s hypermedia events. To provide even notification, two techniques will be considered. The first is server push, a technique which an HTTP connection is kept open between server and client and the server sends data across the connection for the client to process. Typically this is used to provide images which update within a Web browser’s window in which the image is based off of a video stream or some other dynamically changing data source. In this particular instance, the Chimera server would instead stream asynchronous hypermedia events to the client as small formatted text strings. The second technique is one in which a small events-only API is provided for clients to include. The Chimera server will assume that any client which utilizes the HTTP form of the API also utilizes this API and it will establish a connection to the API and send event notifications to it.

7.1.2 Server-To-Server Communication Chimera 2.0 already has servers of different types communicating with each other. For instance, the Chimera server is a client of both the hyperweb manager and the hyperweb server. The hyperweb server is a client of the hyperweb manager. In addition, the hyperweb manager notifies the hyperweb server of changes in the state of the website. Finally, the hyperweb manager, on shutdown, requests the other servers on its site to shutdown as well.

Future research, thus, lies in the area of communication between servers of the same type. In particular, what services are enabled by communication of this type? For example,

147 hyperweb managers communicating with each other can facilitate the replication of a website or load balancing of clients. Hyperweb servers would be able to move or copy hyperwebs between websites. These transfers can be initiated by either a user or a hyperweb manager. The latter would use this capability to carry out its replication responsibilities. Finally, Chimera server communication can address the problem described in Section 4.2 in which a user’s applets are out of synch with the rest of the user’s clients. If an applet’s client server could communicate with the user’s local client server, then it is likely that synchronization can be achieved.

7.1.3 Increased Support for Web Applications Chimera has traditionally been a link-server-based open hypermedia system. Its goal of placing no requirements on the format or storage of a client’s objects prevented a hyperbase approach. However, the advent of the Web, Chimera’s deep integration with it, and the growing number of Web applications enable a new type of open hypermedia system which sits between the two previous types. This Web-based OHS provides a link server for implementing hypermedia services and storing hypermedia information but uses the Web as a hyperbase, i.e., a database for its client’s information. (Note that this does not preclude clients from storing their information outside of the Web. HyperDisco [72] has demonstrated the advantages of an open hyperbase system, one in which use of the hyperbase is optional.) It then offers increased support for those clients which utilize Web protocols and store their content under the name space of a WWW server, i.e., on the Web.

148 Chimera 2.0 is the first step towards developing a Web-based OHS. It provides linkserver capabilities to Web applications but does not take advantage or provide additional services to Web-based applications. Future research must explore the WWW’s potential to function as a hyperbase and define the additional services provided to Chimera clients which use it as such. Some potential benefits include tighter integration with hyperweb browsing mechanisms (since it would be possible to include a link to the application’s objects, or the objects themselves, within a generated HTML page) and inclusion in hyperweb replication mechanisms (since HTTP can be used to transfer the application’s objects between websites).

With respect to the former, a Web-based OHS can leverage its tight integration with the WWW to offer the ability for users to quickly assess the state of a hyperweb from within a standard WWW browser. In Chimera 2.0, since URLs are associated with each hyperweb, CGI-scripts can be written which automatically generate HTML pages listing the links, anchors, etc. of the referenced hyperweb. Clicking on the links contained in this generated HTML will simulate link traversals through this hyperweb and display the content (at least for those applications which store their information within the Web) associated with the views stored in the hyperweb. If this browsing mechanism is augmented by a standard HTML forms interface, then the user can manipulate the state of the hyperweb from within the Web browser itself. Thus, this feature offers a low-cost mechanism to perform hyperweb maintenance.

Future work will explore all these possibilities and further define and delineate the features and capabilities of Web-based open hypermedia systems.

149 7.1.4 Providing Services to the WWW As noted in the related work, the majority of work performed in integrating OHSs with the WWW has as its goal improving or augmenting the hypermedia services provided by the Web. With so much work already there, Chimera 2.0 must strike a balance between providing those features considered “standard” and exploring new research ideas. Standard features include the ability to convert linked text and graphics into HTML, changing the anchors included in HTML dynamically based on the active hyperweb, and creating links between HTML pages and information managed by the OHS’s clients. The Chimera Presence Applet described in Section 4.2.3 already provides the latter feature for Chimera 2.0 users. The other features will be added as Chimera 2.0 matures. Future work in this area includes providing support for distributed authoring and versioning, and improving the interface of the Chimera Presence applet.

A newly-emerging working group for the Internet Engineering Task Force, WEBDAV [68] is an effort to bring distributed authoring and versioning to the WWW. This group has defined extensions to the HTTP protocol which enable the ability to attribute, lock, and version Web resources. Currently, these extensions are being implemented via changes to WWW servers. One area of future work is to explore the possibility of implementing these services with a Web-based OHS such as Chimera 2.0. In particular, a standard WWW server can be augmented to pass WEBDAV-related requests to a Chimera 2.0 hyperweb server. All link-related information can be stored within a hyperweb, thus leveraging its capabilities rather than reinventing them, while the referenced resources are stored in the document space

150 of the Web server. If versioning capabilities are added to Chimera 2.0 in the future, Chimera 2.0 could also offer the ability to version the links related to a Web resource.

With respect to the Chimera Presence applet, future research is needed on improving the presentation mechanism employed in its interface. The current choice of appending the applet to the bottom of the page was chosen for its simplicity. However there are obvious problems with this design such as not being able to see the applet in the case of long HTML pages. Given that users don’t like to scroll to find information [42], it would be desirable to have the applet viewable at all times. This points to placing the applet in an HTML frame, but this solution leads to various compatibility problems with existing Web browsers. Guidance for subsequent designs will be sought by conducting usability studies and examining techniques reported by other researchers (such as the techniques employed in [28]).

7.2 Open Issues in TI Technique Future work for the TI technique involves fleshing out the prototype integrations, increasing the transparency of the technique itself, and addressing various scalability issues.

7.2.1 Proof-of-Concept Prototypes The prototypes described in Section 5.2.1 will be evolved into more complete integrations of Chimera 2.0 with the Java AWT and the subArctic toolkit. As the rest of the widgets are extended, the abstract toolkit and hypermedia interfaces will be developed. Plans are in place to test the reusability benefits provided by these interfaces. The technique will be

151 applied to a different toolkit such as the Tk toolkit associated most closely with the Tcl scripting language. While there will have to be a syntactic conversion of the interfaces, common services, and extended widgets from Java to Tcl (or some other language such as C++), the semantics and structure of the code is expected to be largely preserved.

7.2.2 Transparency Currently, the TI technique constructs a set of extended widgets which are used explicitly by application developers to include hypermedia services in their applications. The advantages of this are the freedom to include hypermedia-enabled widgets into specific areas of a user-interface and the maintenance benefits of having the code for these widgets located in one place. The disadvantages are the slight differences between the original widgets and the extended widgets; more importantly, developers have to modify existing applications or write new applications in order to take advantage of the provided capabilities. To reduce the effort required to use the integrated toolkit, the transparency of the technique to developers will be increased.

A first step in this direction is to eliminate the need for the hypermedia context information required by the extended widgets, thus making the interface to the these widgets identical to the originals. In the case of the prototype, Chimera requires as context information the name of the object and the name of the viewer displaying the object. One approach is to automatically construct an object name by using the concatenation of the widget’s name and all its parents while using the name of the application containing the

152 widget as the viewer name. For example, a button labelled Quit in an application named ChimeraEditor might have the automatically constructed view:

(ChimeraEditor, HFrame:HPanel:HButton:Quit)

This particular algorithm may not be reusable across all open hypermedia systems (because of potential differences in the kinds of information required) but the conceptual architecture can be protected against these differences by the use of abstraction. Having eliminated the differences in the interfaces of the two sets of widgets, techniques in which one widget library is substituted for another may be possible.1 This would allow the inclusion of hypermedia-enabled widgets in pre-existing applications simply by re-linking them or dynamically loading in the appropriate library at run-time. Thus, the potential exists for significantly reducing the developmental effort required to adopt the services provided by the integrated toolkit.

7.2.3 Scalability The TI technique can be used to integrate a toolkit with other services. In fact, a promising target domain for this technique is groupware services. For a particular UI toolkit, the TI technique creates one set of extended widgets for each service integrated. Unfortunately, there is no guarantee these diverse sets of widgets will interoperate. First, there is the cost of connecting to each integrated service. The prototype integrations typically connect the UI toolkits to Chimera in less than one second but as additional services are added, the start-up time will increase. This increase will seem cumbersome to users if it is 1. See, for instance, the Abstract Factory pattern in [21] for a potential object-oriented solution.

153 incurred with each toolkit application. Second, the complexity of error handling increases. How should the toolkit indicate the currently available services? Third, integrated services send events to the widgets at unpredictable times. Since these events may cause application state changes, how does the toolkit manage the scheduling of these potentially conflicting events?

Fortunately, these problems are not insurmountable. It seems likely the first two problems can be solved with a more sophisticated run-time architecture for the integrated toolkit. In this hypothetical run-time, start-up costs are incurred once for the first toolkit application used but not for subsequent toolkit applications. A common service could display the systems currently connected to the toolkit. The third problem, while difficult, already has a suite of techniques for solving it from the research performed in the CSCW domain of synchronous groupware (See [33] for details).

The real scalability issue occurs when a single widget provides access to multiple services simultaneously. Using the current technique described in this paper leads to a combinatorial explosion of extended widgets. For instance, for services A, B, and C, the technique would produce (in addition to the original widget) widget A, widget B, widget C, widget AB, widget AC, and widget ABC. This is clearly unacceptable. An alternative conceptual architecture is based on the idea behind the Decorator design pattern [21]. The Decorator pattern is used in object-oriented toolkits to “decorate” a toolkit component such as adding scrollbars and a border to a text edit widget. The benefit of this pattern is any component can be decorated in this manner, allowing a clean separation of functionality. Text

154 widgets can focus on sophisticated text editing capabilities while the scrollbar decorator can focus on providing advanced scrolling capabilities. Applying this pattern to services, may allow a widget’s behaviors to be extended without having to modify the widget itself. The problems mentioned in the previous paragraph are still relevant (and still solvable) but there are many advantages to this potential technique such as increased transparency and being able to change a widget’s service decorators dynamically at run-time.

CHAPTER 8: Conclusions

The contributions of this dissertation are a set of techniques to be applied in tandem by OHSs for managing various aspects of heterogeneity in modern computing environments, a scalable architecture for integrating OHSs with the WWW, and a technique for integrating user-interface toolkits with OHSs. These contributions are united by their ability to support large-scale information environments. There is no official definition for this term, however the characteristics of large-scale information environments can be approximated by considering the directions of the fields of distributed object technologies (such as CORBA [51] or DCOM [46]), the WWW, supercomputers, and digital libraries. These environments must be able to handle millions of users, petabytes of information, terabytes of network communications, and thousands of applications.1 At the same time, these environments must provide advanced user-interface services, hypermedia services, and CSCW services to each individual user so that the information is accessible, searchable, sharable, and understandable. An example of research being performed in this area is the MDAS project at the San Diego Supercomputer Center [59]. Another example is the PetaPlex project of Knowledge Systems Incorporated [37]. This project is developing a large-scale digital library for the United States Intelligence community. The objectives are the projects are summarized in [38]:

“The specific goals targeted in the current phase of the project is to develop an architecture capable of scaling to 20 petabytes on-line with subsecond response time to access random, fine-grained URN-specified objects, at a sustained rate in excess of 30 million 1. A petabtye is 250 bytes or 1024 terabytes.

155

156 transactions per second. The current statement of work calls for integrating one million, 20 Gb disks into a coherent system that can attain these performance objectives --- at acceptable cost.”

The intelligence community currently manages about 2 petabytes of information [1]. This information is growing at roughly 4 terabytes of information per day. As more information sources are integrated and as the amount of information by existing sources increases, it is anticipated that intelligence information will eventually grow at the rate of 15 terabytes per day. As mentioned above, once all of this information is stored, it must then be accessible. The PetaPlex designers have the goal of supporting up to one hundred thousand simultaneous queries over the information at any point in time.

In my survey paper [3], I examined the requirements that large-scale information environments would impose on the fields of software engineering, hypermedia, computerhuman interaction, and computer-supported collaborative work. My final recommendations are summarized in Table 8-1. While these requirements are stated in a somewhat simplistic fashion, they identify key design principles for the construction of large-scale information environments. My dissertation work focused on the field of hypermedia and in particular techniques associated with open hypermedia systems. The contributions of this dissertation address recommendations 5, 6, 7, and 10 from Table 8-1. In addition, they point out the need for additional recommendations. These new recommendations can be stated simply as:

1. Support Heterogeneity.

157 Table 8-1. Summary of Requirements for Large-Scale Information Environments 1. Build explicit architectures using design environments augmented by design tools. 2. Maintain a separation of concerns with respect to information and its presentation. 3. Allow users to easily specify the presentation of information. 4. Provide high-level user-interface tools. 5. Ensure that access to information is consistent across applications. 6. Allow third-party tools to be integrated without modification. 7. Allow for the same information to be viewed, anchored, and linked in more than one way. 8. Allow the data model and its operations to be dynamically extensible. 9. Provide a scripting language to end users. 10. Present a low-entry barrier and a gradual learning curve. 11. Support the human as an information resource. 12. Be responsive and configurable to a group’s process and political needs. 13. Support a range of collaborative sessions between users. 2. Leverage the World Wide Web. 3. Integrate Infrastructure. The thirteen original recommendations implicitly recommend “Support Heterogeneity” but the research in this dissertation points out the need to consider the explicit ramifications of support for heterogeneity. In particular, abstraction must be used in several dimensions (client and server architecture, underlying conceptual framework, etc.), multiple programming languages, and hardware platforms must be supported, and in combination with recommendation 10, an incremental adoption of the system must be possible. Leveraging the strengths of the World Wide Web has provided the tangible benefits of global distribution, scalable architectures, and common user-interaction styles to my work in

158 open hypermedia systems. With respect to large-scale information environments it offers several opportunities. Despite its various weaknesses, the Web can be considered a prototype for a large-scale information environment. It already provides millions of people with access to gigabytes of information. However, it cannot be considered a full-fledged large-scale information environment since it lacks advanced hypermedia services, standard collaboration services, and the tools to enable effective understanding by its users of the information contained within. However, it serves as an excellent vehicle for experimentation in large-scale information environments. As new capabilities are added to the Web it will essentially evolve into a large-scale information environment. My work (along with the related work described in Section 2.2) has demonstrated some of the benefits gained by integrating advanced hypermedia systems with the WWW. Any large-scale information environment will need to be able to access information stored in the Web–it would be infeasible to replicate or copy the distributed information of the Web into another system–so the integration between them should be an explicit design goal. Finally, the fact that the Web is based on standard protocols and that the process for developing is standards is open, large-scale information environment developers have the ability to influence and design the next generation of Web infrastructure to meet their needs.

The third recommendation based on the contributions of this dissertation is “Integrate Infrastructure.” This is a lesson learned from the work on alternative integration techniques with OHSs. Previous integration techniques focused on integrating one application into the OHS at a time. The TI technique essentially integrates an infrastructure from which an entire class of applications is integrated at once. In the case of the TI technique

159 the infrastructure is user-interface toolkits, and the class of applications is thus any application which makes use of the integrated toolkit. Since the differences between the original toolkit and the integrated toolkit are minimal, once the integration is performed only a small amount of work is required by application developers to migrate their existing applications to take advantage of the new services. The technique has been successfully demonstrated with two existing user-interface toolkits (although as noted in Section 5 the integrations were achieved at different levels of quality of service). Now additional infrastructure needs to be integrated. This integrated infrastructure will then act as a harness integrating their client applications and automatically providing some default level of hypermedia services. Possible infrastructure targets include process modeling and enactment systems such as Endeavors [10], testing automation systems such as TAOS [56], and component architectures such as Java Beans [65].

As these various forms of infrastructure are integrated, hypermedia services become pervasive throughout a user’s environment. Since all hypermedia services are provided by a common underlying (distributed) system, the user enjoys the benefits that come with consistency, such as the ability to reuse hypermedia knowledge learned in one application in another. The user spends less time learning the services than using them. The benefits of pervasive hypermedia are not limited to just the user. Since the services are built up on top of layers of APIs which are accessible from all integrated infrastructure, programs of all types, including mobile agents, Web crawlers, applets, CORBA objects, and monolithic systems can reliably depend on having access to hypermedia services. The result is just one small part of a large-scale information system. However, without it, the ultimate achievement of large-scale information environments would not be possible.

REFERENCES

1.

Robert Akscyn. A Closed Path to Open Systems. Presented at the 3rd Workshop on Open Hypermedia Systems, April 4 1997.

2.

Kenneth M. Anderson, Richard N. Taylor, and E. James Whitehead, Jr. Chimera: Hypertext for Heterogeneous Software Environments. In Proceedings of the ACM European Conference on Hypermedia Technology, pages 94-107, Edinburgh, Scotland, ACM Press, September 18-23 1994.

3.

Kenneth M. Anderson. Enabling Large-Scale Information Integration: A Survey of Previous Work. Unpublished manuscript, Irvine, CA, USA. February 1995.

4.

Kenneth M. Anderson. Extending User-Interface Toolkits with Hypermedia Functionality. In Proceedings of the Thirtieth Annual Hawaii International Conference on System Sciences, Vol. 6, pages 197-206, Wailea, Hawaii, USA, IEEE Computer Society Press, January 7-10 1997.

5.

Kenneth M. Anderson. Integrating Open Hypermedia Systems with the World Wide Web. In Proceedings of the Eighth ACM Conference on Hypertext, pages 157-166, Southampton, UK, ACM Press, April 6-11 1997.

6.

Tim Berners-Lee, R. Cailliau, J.-F. Groff, and B. Pollermann. World-Wide Web: The Information Universe. Electronic Networking: Research, Applications, and Policy, 2(1):52-58, January 1992.

7.

Tim Berners-Lee and D. Connolly. HyperText Markup Language Specification -- 2.0. Internet Proposed Standard RFC 1866. MIT/W3C, November 1995.

8.

Tim Berners-Lee. WWW: Past, Present, and Future. Computer, 29(10):69-77, October 1996.

9.

Tim Berners-Lee, Roy Fielding, and L. Masinter. Uniform Resource Locators (URL): Generic Syntax and Semanitcs. Internet-Draft (work in progress) MIT/LCS, UC Irvine, Xerox, May 1997.

10.

Gregory Alan Bolcer and Richard N. Taylor. Endeavors: A Process System Integration Infrastructure. In Proceedings of the 4th International Conference on Software Process, Brighton, UK, December 2-6 1996.

11.

Brad Campbell and Joseph M. Goodman. HAM: A General-Purpose Hypertext Abstract Machine. In Proceedings of the First ACM Conference on Hypertext, pages 2132, Chapel Hill, North Carolina, USA, ACM Press, November 13-15 1987.

160

161 12.

Leslie Carr, Gary Hill, David De Roure, Wendy Hall, and Hugh Davis. Open Information Services. Computer Networks and ISDN Systems, 28(7-11):1027-1036 1996.

13.

Jeff Conklin. Hypertext: An Introduction and Survey. IEEE Computer, 20(9):17-41, September 1987.

14.

Hugh Davis, Wendy Hall, Ian Heath, Gary Hill, and Rob Wilkins. Towards an Integrated Information Environment with Open Hypermedia Systems. In Proceedings of the Fourth ACM Conference on Hypertext, pages 181-190, Milano, Italy, ACM Press, November 30-December 4 1992.

15.

Hugh C. Davis, Simon Knight, and Wendy Hall. Light Hypermedia Link Services: A Study of Third Party Application Integration. In Proceedings of the ACM European Conference on Hypermedia Technology, pages 41-50, Edinburgh, Scotland, ACM Press, September 18-23 1994.

16.

Hugh Davis, Andy Lewis, and Antoine Rizk. OHP: A Draft Proposal for a Standard Open Hypermedia Protocol. In Proceedings of the 2nd Workshop on Open Hypermedia Systems, U.K. Wiil and S. Demeyer, Editors. Department of Information and Computer Science, University of California, Irvine. 1996.

17.

Prasun Dewan. A Tour of the Suite User Interface Software. In Proceedings of the Third Annual Symposium on User Interface Software and Technology, pages 57-65, Snowbird, UT, USA, ACM Press, October 1990.

18.

J. E. Drufke, Jr., John J. Leggett, David L. Hicks, and John L. Schnase. The Derivation of a Hypertext Widget Class from the Athena Text Widget. Technical Report TAMU-HRL 91-002. Hypertext Research Lab, Texas A&M University, College Station, Texas, USA. April 1991.

19.

Roy T. Fielding, J. Gettys, J. Mogul, H. Frystyk, and Tim Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. Internet Proposed Standard RFC 2068. UC Irvine, DEC, MIT/LCS, January 1997.

20.

Michael Franz, .

21.

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, USA, 1995.

22.

Alejandra Garrido and Gustavo Rossi. A Framework for Extending Object-Oriented Applications with Hypermedia Functionality. The New Review of Hypermedia and Multimedia: Applications and Research, 2 1996.

162 23.

Kaj Grønbæk and Randall H. Trigg. Design Issues for a Dexter-Based Hypermedia System. In Proceedings of the Fourth ACM Conference on Hypertext, pages 191-200, Milano, Italy, ACM Press, November 30-December 4 1992.

24.

Kaj Grønbæk, Jens A. Hem, Ole L. Madsen, and Lennert Sloth. Designing DexterBased Cooperative Hypermedia Systems. In Proceedings of the Fifth ACM Conference on Hypertext, pages 25-38, Seattle, WA, USA, ACM Press, November 14-18 1993.

25.

Kaj Grønbæk. Composites in a Dexter-Based Hypermedia Framework. In Proceedings of the ACM European Conference on Hypermedia Technology, pages 59-69, Edinburgh, Scotland, ACM Press, September 18-23 1994.

26.

Kaj Grønbæk and Randall H. Trigg. Design Issues for a Dexter-Based Hypermedia System. Communications of the ACM, 37(2):40-49, February 1994.

27.

Kaj Grønbæk and Randall H. Trigg. Toward a Dexter-Based Model for Open Hypermedia: Unifying Embedded References and Link Objects. In Proceedings of the Seventh ACM Conference on Hypertext, pages 149-160, Washington DC, USA, ACM Press, March16-20 1996.

28.

Kaj Grønbæk, Niels Olof Bouvin, and Lennert Sloth. Designing Dexter-Based Hypermedia Services for the World Wide Web. In Proceedings of the Eighth ACM Conference on Hypertext, pages 146-156, Southampton, UK, ACM Press, April 6-11 1997.

29.

Frank Halasz. Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems. Communications of the ACM, 31(7):836-852, July 1988.

30.

Frank Halasz and Mayer Schwartz. The Dexter Hypertext Reference Model. In Proceedings of the Hypertext Standardization Workshop, pages 95-133, Gaithersburg, MD, USA, National Institute of Standards, January 1990.

31.

Frank Halasz and Mayer Schwartz. The Dexter Hypertext Reference Model. Communications of the ACM, 37(2):30-39, February 1994.

32.

Wendy Hall, Hugh Davis, and Gerard Hutchings. Rethinking Hypermedia: The Microcosm Approach. Kluwer Academic Publishers, London, 195 pages, 1996.

33.

Ralph D. Hill, Tom Brinck, Steven L. Rohall, John F. Patterson, and Wayne Wilner. The Rendezvous Architecture and Language for Constructing Multiuser Applications. ACM Transactions on Computer-Human Interaction, 1(2):81-125, June 1994.

34.

Scott Hudson, .

163 35.

Charles Kacmar and John J. Leggett. PROXHY: A process-oriented extensible hypertext architecture. ACM Transactions on Information Systems, 9(4):339-419, October 1991.

36.

Charles J. Kacmar. A Process Approach for Providing Hypermedia Services to Existing, Non-Hypermedia Applications. Electronic Publishing: Organization, Dissemination, and Distribution, 8(1):31-48, January 1995.

37.

Knowledge Systems Inc., .

38.

Knowledge Systems Inc., .

39.

John J. Leggett and John L. Schnase. Viewing Dexter with Open Eyes. Communications of the ACM, 37(2):76-86, February 1994.

40.

MacroMedia Inc., .

41.

Kathryn C. Malcolm, Steven E. Poltrock, and Douglas Schuler. Industrial Strength Hypermedia: Requirements for a Large Engineering Enterprise. In Proceedings of the Third ACM Conference on Hypertext, pages 13-24, San Antonio, Texas, USA, ACM Press, December 15-18 1991.

42.

Hermann Maurer. Hyper-G now, HyperWave: The Next Generation Web Solution. Addison-Wesley, Harlow, England, 1996.

43.

Mark J. Maybee, Dennis H. Heimbigner, and Leon J. Osterweil. Multilanguage Interoperability in Distributed Systems: Experience Report. In Proceedings of the Eighteenth International Conference on Software Engineering, pages 451-463, Berlin, Germany, IEEE Press, March 1996.

44.

Metrowerks Inc., .

45.

Norman Meyrowitz. The Missing Link: Why We're All Doing Hypertext Wrong. In The Society of Text: Hypertext, Hypermedia and the Social Construction of Information. MIT Press. pages 107-114. 1989.

46.

Microsoft Inc., .

47.

Brad A. Myers, et al. The Amulet Environment: New Models for Effective User Interface Software Development. Technical Report CMU-CS-96-189. School of Computer Science, Carnegie Mellon University, November 1996.

48.

Netscape Inc., .

49.

Jakob Nielsen. Usability Engineering. AP Professional, Boston, MA, USA, 1993.

164 50.

Peter J. Nürnberg, John J. Leggett, Erich R. Schneider, and John L. Schnase. Hypermedia Operating Systems: A New Paradigm for Computing. In Proceedings of the Seventh ACM Conference on Hypertext, pages 194-202, Washington DC, USA, ACM Press, March 16-20 1996.

51.

Robert Orfali, Dan Harkey, and Jeri Edwards. The Essential Distributed Objects Survival Guide. John Wiley & Sons, Inc., New York, NY, USA, 604 pages, 1996.

52.

Kasper Østerbye and Uffe Kock Wiil. The Flag Taxonomy of Open Hypermedia Systems. In Proceedings of the Seventh ACM Conference on Hypertext, pages 129-139, Washington DC, USA, ACM Press, March 16-20 1996.

53.

ParcPlace Systems Inc. VisualWorks 2.0 User's Guide. Sunnyvale, CA, USA. 1994.

54.

Amy Pearl. Sun's Link Service: A Protocol for Open Linking. In Proceedings of the Second ACM Conference on Hypertext, pages 137-146, Pittsburgh, Pennsylvania, USA, ACM Press, November 5-8 1989.

55.

J. J. Puttress and N. M. Guimaraes. The Toolkit Approach to Hypermedia. In Proceedings of the European Conference on Hypermedia Technology, pages 25-37, Versailles, France, November 1990.

56.

Debra J. Richardson. TAOS: Testing with Analysis and Oracle Support. In Proceedings of the International Symposium on Software Testing and Analysis, August 1994.

57.

Antoine Rizk and Louis Sauter. Multicard: An Open Hypermedia System. In Proceedings of the Fourth ACM Conference on Hypertext, pages 4-10, Milano, Italy, ACM Press, November 30-December 4 1992.

58.

Mark Roseman and Saul Greenberg. Building Real-Time Groupware with GroupKit. ACM Transactions on Computer-Human Interaction, 3(1):66-106, March 1996.

59.

San Diego Supercomputer Center, .

60.

John Schnase, John J. Leggett, David L. Hicks, Peter J. Nürnberg, and J. A. Sanchez. HB1: Design and Implementation of a Hyperbase Management System. Electronic Publishing: Origination, Dissemination, and Design, 6(1):35-63, July 1993.

61.

John L. Schnase, John J. Leggett, David L. Hicks, Peter J. Nürnberg, and J. A. Sanchez. Open Architectures for Integrated Hypermedia-Based Information Systems. In Proceedings of the 27th Hawaii International Conference on System Sciences, Maui, Hawaii, IEEE Press, January 1994.

62.

John B. Smith and F. Donelson Smith. ABC: A Hypermedia System for ArtifactBased Collaboration. In Proceedings of the Third ACM Conference on Hypertext, pages 179-192, San Antonio, Texas, USA, ACM Press, December 15-18 1991.

165 63.

Norbert Streitz, Jörg Haake, Jörg Hannemann, Andreas Lemke, Wolfgang Schuler, Helge Schütt, and Manfred Thüring. SEPIA: A Cooperative Hypermedia Authoring Environment. In Proceedings of the Fourth ACM Conference on Hypertext, pages 11-22, Milano, Italy, ACM Press, November 30-December 4 1992.

64.

Sun Microsystems Inc., .

65.

Sun Microsystems Inc., .

66.

Richard N. Taylor, Kari A. Nies, Gregory Alan Bolcer, Craig A. MacFarlane, Kenneth M. Anderson, and Gregory F. Johnson. Chiron-1: A Software Architecture for User Interface Development, Maintenance, and Run-Time Support. ACM Transactions on Computer-Human Interaction, 2(2):105-144, June 1995.

67.

E. James Whitehead, Jr. An Architectural Model for Application Integration in Open Hypermedia Environments. In Proceedings of the Eighth ACM Conference on Hypertext, pages 1-12, Southampton, UK, ACM Press, April 6-11 1997.

68.

E. James Whitehead, Jr. World Wide Web Distributed Authoring and Versioning (WEBDAV): An Introduction. ACM Standard View, March 1997.

69.

Uffe Kock Wiil and Kasper Østerbye. Experiences with HyperBase: A Multi-User Back-End for Hypertext Applications with an Emphasis on Collaboration Support. Technical Report R-90-38. Department of Computer Science, The University of Aalborg, Aalborg, Denmark. October 1990.

70.

Uffe Kock Wiil and John J. Leggett. Hyperform: Using Extensibility to Develop Dynamic, Open and Distributed Hypertext systems. In Proceedings of the Fourth ACM Conference on Hypertext, pages 251-261, Milano, Italy, ACM Press, November 30December 4 1992.

71.

Uffe Kock Wiil and Kasper Østerbye. Proceedings of the ECHT'94 Workshop on Open Hypermedia Systems. Technical Report R-94-2038. Department of Computer Science, Aalborg University, Aalborg, Denmark. 1994.

72.

Uffe Kock Wiil and John J. Leggett. The HyperDisco Approach to Open Hypermedia Systems. In Proceedings of the Seventh ACM Conference on Hypertext, pages 140-148, Washinton DC, USA, ACM Press, March 16-20 1996.

73.

Uffe Kock Wiil and Serge Demeyer. Proceedings of the 2nd Workshop on Open Hypermedia Systems. ICS Technical Report UCI-ICS-96-10. Department of Information and Computer Science, University of California, Irvine, Irvine, CA, USA. April 1996.

166 74.

Uffe Kock Wiil, Ed. Proceedings of the 3rd Workshop on Open Hypermedia Systems. Technical Report, The Danish National Centre for IT Research, Aarhus, Denmark. June 1997.

75.

Uffe Kock Wiil and John J. Leggett. Workspaces: The HyperDisco Approach to Internet Distribution. In Proceedings of the Eighth ACM Conference on Hypertext, pages 13-23, Southampton, UK, ACM Press, April 6-11 1997.

76.

World Wide Web Consortium, .

APPENDIX A: Chimera Application Program Interface

The Chimera Server Application Program Interface (API) is the primary means by which Chimera clients communicate with the Chimera server. Listed below are the operations provided by the API. These operations allow Clients to connect to and disconnect from the Chimera server, connect to Chimera websites and select among Chimera hyperwebs, and finally, manipulate the contents of a hyperweb including registering new viewers, objects, views, anchors, or links. The routines are presented using pseudo-Java syntax and have been slightly sanitized for presentation purposes. For instance, all API operations can generate exceptions to indicate error conditions, however the specification of the exceptions is not shown here. The full version of the Chimera API can be obtained from the Chimera website which is currently located at .

167

168

Connection Routines The following operations enable a client to connect to a Chimera server and then request it to connect to a Chimera 2.0 website. The corresponding routines for disconnection of these elements are also listed. connect void connect(String clientName) This routine establishes a connection to a local Chimera server. Parameters: clientName - The name of the client application. This name may be used by the server to generate information about the clients connected to it. This name is not as important as the viewer name specified when creating a viewer. This latter name is significant since it is used to determine the invocation of clients in response to delayed link traversals. connectApplet void connectApplet(String hostName, String userName, String clientName) This routine allows applets to establish a connection to a remote Chimera server on the machine from which the applet was downloaded. Because of Java security restrictions, it has more parameters than its counterpart for applications. Parameters: hostName - The host machine of the applet. Can be determined from either getDocumentBase() or getCodeBase(). userName - A Java applet can not automatically determine the it's user's name. Thus, an applet must query its user for their name and pass the response here. clientName - The name of the client application. This name may be used by the server to generate information about the clients connected to it. This name is not as important as the viewer name specified when creating a viewer. This latter name is significant since it is used to determine the invocation of clients in response to delayed link traversals.

169 connectHyperwebManager boolean connectHyperwebManager(String hwm) Sets the current hyperweb manager of the Chimera server. This determines the webs which are available to the chimera server. These webs can be accessed by first calling getWebs and then setting the desired web with the setWeb call. Input is of the form: . Parameters: hwm - The URL of a Chimera-enhanced website. Returns: TRUE if the specified Hyperweb Manager is successfully contacted. disconnect void disconnect() Disconnects the client from its Chimera server. disconnectHyperwebManager void disconnectHyperwebManager() Disconnects the client's Chimera server from the active Chimera 2.0 website. The client is still connected to the Chimera server. isHwmConnected boolean isHwmConnected() Returns: TRUE if the Chimera server is connected to a Chimera 2.0 website.

170

Run-Time Modeling These routines enable the Chimera server to actively model its run-time environment. There are routines to specify active views and viewers, to manage the active link, to manipulate the active hyperweb and website, and to register interest in hypermedia events. Routines which reverse some of these operations are also listed. activeView void activeView(viewerId v, viewId vw) Informs the Chimera server that the specified view is active within the specified viewer. Parameters: v - The active viewer. vw - The active view. activeViewer void activeViewer(viewerId v) Informs the Chimera server that the specified viewer is now active within the client. Parameters: v - The active viewer. addAnchorToActiveLink void addAnchorToActiveLink(anchorId a) Adds the specified anchor to the active link. Parameters: a - The anchor being added.

171 addViewToActiveLink void addViewToActiveLink(viewId v) Adds the specified anchor to the active link. Parameters: v - The view being added. clearWeb void clearWeb() Deselects the current hyperweb. At this point there will be no anchors or links available until another web is selected as the result of a call to setWeb(). deregisterInterest void deregisterInterest(viewerId v, event e) Deregisters interest in a particular event for a particular viewer. The specified viewer must be active within the client which is indicated by calling activeViewer(). Passing null for the event parameter will deregister interest in all events except activeSite and activeWeb. Parameters: v - The viewer deregistering interest in an event type. e - An instance of an the event type in question. getActiveLink linkId getActiveLink() Retrieves the active link. Returns: null if there is no active link, otherwise the id of the active link.

172 getWeb String getWeb() Returns: The name of the active hyperweb or null. getWebs String[] getWebs() Returns: The names of all the hyperwebs located on the active Chimera 2.0 website. inactiveView void inactiveView(viewerId v, viewId vw) Informs the Chimera server that the specified view is no longer active within the specified viewer. inactiveViewer void inactiveViewer(viewerId v) Informs the Chimera server that the specified viewer is no longer active within the client. registerInterest void registerInterest(viewerId v, event e) Registers interest in a particular event for a particular viewer. The client must call activeViewer on the viewerId before calling registerInterest with it as a parameter. Passing null for the event parameter will register interest in all events. Note: all clients are automatically assigned interest in activeSite and activeWeb events, and interest in these two events cannot be deregistered. Parameters: v - The specified viewer. e - An instance of an the event type in question.

173 setActiveLink boolean setActiveLink(linkId l) Makes the specified link active, or shared, between all of a user's clients. To clear the active link, pass null as the parameter. Returns false if the specified link does not exist, false otherwise. Note: the calling client will receive an activeLink event as a result of this call, if it has registered interest in activeLink events. Parameters: l - The specified link. setWeb boolean setWeb(String name) Sets the Chimera Server to access the specified hyperweb. Returns: TRUE if the web is valid, FALSE otherwise.

174

Locking These routines enable a client to lock and unlock hypermedia concepts. In addition, one routine allows a client to check to see if a hypermedia concept has a lock associated with it. lockConcept boolean lockConcept(conceptId c) Obtains a lock on the specified concept. Parameters: c - The specified hypermedia concept. locked boolean locked(conceptId c) Checks to see if a lock is held on the specified concept. Parameters: c - The specified hypermedia concept. Returns: TRUE if a lock is held. unlockConcept boolean unlockConcept(conceptId c) Releases the lock held by a client on a particular concept. Parameters: c - The specified hypermedia concept. Returns: TRUE if successful.

175

Traversal The following routines enable link traversal. The first is a generic routine which allows a client to completely specify the semantics for a link traversal. The remaining operations invoke various aspects of Chimera's default link traversal semantics. initiateTraversal void initiateTraversal(String algorithm, csTraversalInfo info) Initiates a link traversal using the specified algorithm and traversal information. If the algorithm is not specified, the Chimera server will use default link traversal semantics. traverseLink void traverseLink(linkId l, anchorId a) Traverse the specified link starting from the specified anchor. Parameters: l - The specified link. a - The specified anchor. traverseLink void traverseLink(linkId l, viewId v) Traverse the specified link starting from the specified view. Parameters: l - The specified link. v - The specified view.

176 traverseLinks void traverseLinks(anchorId a) Traverse all links containing the specified anchor. Parameters: a - The specified anchor. traverseLinks void traverseLinks(viewId v) Traverse all links containing the specified view. Parameters: v - The specified view. traverseTo void traverseTo(anchorId a) Traverse to the specified anchor. Parameters: a - The specified anchor. traverseTo void traverseTo(viewId v) Traverse to the specified view. Parameters: v - The specified view.

177

Attributes The following routines allow clients to assign and retrieve attribute information on hypermedia concepts. clearAttributes void clearAttributes(conceptId c) Deletes all attributes associated with the specified concept. Parameters: c - The concept being cleared. deleteAttribute void deleteAttribute(conceptId c, String name) Deletes the specified attribute from the specified concept. Parameters: c - The specified hypermedia concept. name - The name of the attribute to delete. getAttribute String getAttribute(conceptId c, String name) Retrieves the value of the specified attribute. Parameters: c - The specified hypermedia concept. name - The name of the attribute to delete. Returns: The value of the attribute.

178 getAttributes attribute[] getAttributes(conceptId c) Retrieves all attributes associated with the specified concept. Parameters: c - The specified hypermedia concept. Returns: An array of attributes associated with the specified concept. numberOfAttributes int numberOfAttributes(conceptId c) Retrieves the number of attributes associated with the concept. Parameters: c - The specified hypermedia concept. setAttribute void setAttribute(conceptId c, attribute a) Assigns the specified attribute to the specified concept. Parameters: c - The specified hypermedia concept. a - The specified attribute.

179 setAttribute void setAttribute(conceptId c, String name, String value) Assigns the specified attribute to the specified concept. Parameters: c - The specified hypermedia concept. name - The name of the attribute. value - The value of the attribute. setAttributes void setAttributes(conceptId c, attribute attrs[]) Assigns the specified attributes to the specified concept. Parameters: c - The specified hypermedia concept. attrs - An array of attributes.

180

Anchors The following operations enable the manipulation of anchors. These operations include the ability to create, delete, edit, and query anchors. anchorExists boolean anchorExists(anchorId a) Checks to see if the specified anchor exists in the hyperweb. Parameters: a - The specified anchor. createAnchor anchorId createAnchor(viewId v) Creates a new anchor on the specified view. Parameters: v - The specified view. Returns: The id of the newly created anchor. createAnchor anchorId createAnchor(objectId o) Creates a new anchor on the specified object. Parameters: o - The specified object. Returns: The id of the newly created anchor.

181 deleteAnchor void deleteAnchor(anchorId a) Deletes the specified anchor from the hyperweb. Note: Chimera maintains the consistency of the hyperweb. It will remove the specified anchor from any links which contain it before deleting the anchor. Parameters: a - The anchor to delete. getAnchors anchorId[] getAnchors() Retrieves all anchors in the hyperweb. Returns: All anchors associated with the active hyperweb. getObject objectId getObject(anchorId a) Retrieves the object of the specified anchor. Parameters: a - The specified anchor. Returns: The id of the object of the specified anchor. getView viewId getView(anchorId a) Retrieves the view of the specified anchor. Parameters: a - The specified anchor.

182 numberOfAnchors int numberOfAnchors() Retrieves the number of anchors in the hyperweb. viewSpecific boolean viewSpecific(anchorId a) Checks to see if the specified anchor is view-specific. Parameters: a - The specified anchor.

183

Links The following operations enable the manipulation of links. These operations include the ability to create, delete, edit, and query links. addAnchor void addAnchor(linkId l, anchorId a) Adds the specified anchor to the specified link. Parameters: l - The link. a - The anchor being added. addView void addView(linkId l, viewId v) Adds the specified view to the specified link. Parameters: l - The link. v - The view being added. This view will be treated as an anchor with respect to other link related functions such as numberOfAnchors, etc. containsAnchor boolean containsAnchor(linkId l, anchorId a) Checks to see if the specified link contains the specified anchor. Parameters: l - The specified link. a - The specified anchor. Returns: TRUE if the link contains the anchor.

184 containsView boolean containsView(linkId l, viewId v) Checks to see if the specified link contains the specified view. Parameters: l - The specified link. v - The specified view. Returns: TRUE if the link contains the view. createLink linkId createLink() Creates a new empty link. Returns: The id of the newly created link. deleteLink void deleteLink(linkId l) Deletes the specified link from the hyperweb. Parameters: l - The specified link.

185 getAnchors anchorId[] getAnchors(linkId l) Retrieves all anchors contained in the specified link. Parameters: l - The specified link. Returns: All anchors associated with the specified link. getLinks linkId[] getLinks() Retrieves all links in the hyperweb. Returns: All links associated with the active hyperweb. getLinksWith linkId[] getLinksWith(anchorId a) Retrieves all links which contain the specified anchor. Parameters: a - The specified anchor. Returns: All links associated with the active hyperweb which contain the specified anchor.

186 getLinksWith linkId[] getLinksWith(viewId v) Retrieves all links which contain the specified view. Parameters: v - The specified view. Returns: All links associated with the active hyperweb which contain the specified view. linkExists boolean linkExists(linkId l) Checks to see if the specified link exists in the hyperweb. Parameters: l - The specified link. numberOfAnchors int numberOfAnchors(linkId l) Retrieves the number of anchors in the specified link. Parameters: l - The specified link. numberOfLinks int numberOfLinks() Retrieves the number of links in the hyperweb.

187 numberOfLinksWith int numberOfLinksWith(anchorId a) Retrieves the number of links in the hyperweb which contain the specified anchor. Parameters: a - The specified anchor. numberOfLinksWith int numberOfLinksWith(viewId v) Retrieves the number of links in the hyperweb which contain the specified view. Parameters: v - The specified view. removeAnchor void removeAnchor(linkId l, anchorId a) Removes the specified anchor from the specified link. Parameters: l - The specified link. a - The specified anchor. removeView void removeView(linkId l, viewId v) Removes the specified view from the specified link. Parameters: l - The specified link. v - The specified view.

188

Objects The following operations enable the manipulation of objects. These operations include the ability to create, delete, edit, and query objects. addObject void addObject(objectId comp, objectId o) Adds the specified object to the specified composite object. Note: Chimera automatically changes non-composite objects to composite objects the first time an object is added to it. Parameters: comp - The composite object. o - The object being added. createObject objectId createObject(String objectName, String MIMEtype) Creates a new object with the specified name and MIMEtype, unless this object already exists for the active website. In that case, it simply returns the id of the existing object. Parameters: objectName - The name of the object. This string can be anything, however it is recommended that, where possible, a URL for the object be used. MIMEtype - The MIME type of the object. Returns: The id of the newly created object, or the id of the previously registered object. deleteObject void deleteObject(objectId o) Deletes the specified object from the hyperweb. Note: Chimera maintains the consistency of the hyperweb. This operation will delete any views based off this object, delete any anchors associated with those views, along with any anchors associated with

189 the object itself (this includes removing these anchors from any links which contain them) before deleting the object. Parameters: o - The specified object. getAnchors anchorId[] getAnchors(objectId o) Retrieves all anchors contained in the specified object. Parameters: o - The specified object. Returns: All anchors in the active hyperweb based off the specified object. getMIMEtype String getMIMEtype(objectId o) Retrieves the MIMEtype of the specified object. Parameters: o - The specified object. Returns: The MIME type of the specified object.

190 getObject objectId getObject(String name) Retrieves the object with the specified name. Parameters: name - The specified name. Returns: The id of the object with the specified name. getObjectName String getObjectName(objectId o) Retrieves the name of the specified object. Parameters: o - The specified object. Returns: The name of the specified object. getObjects objectId[] getObjects() Retrieves all objects in the hyperweb. Returns: All objects associated with the active hyperweb.

191 getObjects objectId[] getObjects(objectId o) Retrieves all objects which make up the specified composite object. Parameters: o - The specified object. Returns: All objects associated with the specified object. isComposite boolean isComposite(objectId o) Note: To make an object a composite object, simply add an object to it, using addObject(). Parameters: o - The specified object. Returns: TRUE if an object is a composite. numberOfAnchors int numberOfAnchors(objectId o) Retrieves the number of anchors in the specified object. Parameters: o - The specified object. numberOfObjects int numberOfObjects() Retrieves the number of objects in the hyperweb.

192 numberOfObjects int numberOfObjects(objectId o) Retrieves the number of objects in the specified composite. Parameters: o - The specified object. objectExists boolean objectExists(String name) Checks to see if the object with the specified name exists on the active website. Parameters: name - The specified object name. objectExists boolean objectExists(objectId o) Checks to see if the specified object exists in the hyperweb. Parameters: o - The specified object.

193

Views The following operations enable the manipulation of views. These operations include the ability to create, delete, edit, and query views. createView viewId createView(viewerId v, objectId o) Creates a new view with the specified viewer and object, unless this view already exists for the active website. In that case, it simply returns the id of the existing view. Returns: The id of the newly created view, or the id of the previously registered view. deleteView void deleteView(viewId v) Deletes the specified view from the hyperweb. Note: Chimera maintains the consistency of the hyperweb. This operation will delete any anchors associated with this view (this includes removing these anchors from any links which contain them) before deleting the view. Parameters: v - The specified view. getAnchors anchorId[] getAnchors(viewId v) Retrieves all anchors contained in the specified view. Parameters: v - The specified view. Returns: All anchors in the active hyperweb based off the specified view.

194 getObject objectId getObject(viewId v) Retrieves the object of the specified view. Parameters: v - The specified view. Returns: The id of the object of the specified view. getView viewId getView(viewerId v, objectId o) Retrieves the view with the specified viewer and object. Parameters: v - The specified viewer. o - The specified object. getViewer viewerId getViewer(viewId v) Retrieves the viewer of the specified view. Parameters: v - The specified view. getViews viewId[] getViews() Retrieves all views in the hyperweb.

195 getViewsWith viewId[] getViewsWith(objectId o) Retrieves all views which contain the specified object. Note: this call does not take into consideration the objects contained in composite objects. Parameters: o - The specified object. getViewsWith viewId[] getViewsWith(viewerId v) Retrieves all views which contain the specified viewer. Parameters: v - The specified viewer. numberOfAnchors int numberOfAnchors(viewId v) Retrieves the number of anchors in the specified view. Parameters: v - The specified view. numberOfViews int numberOfViews() Retrieves the number of views in the hyperweb. numberOfViewsWith int numberOfViewsWith(objectId o) Retrieves the number of views in the hyperweb which contain the specified object. Parameters: o - The specified object.

196 numberOfViewsWith int numberOfViewsWith(viewerId v) Retrieves the number of views in the hyperweb which contain the specified viewer. Parameters: v - The specified viewer. viewExists boolean viewExists(viewerId v, objectId o) Checks to see if the specified view exists in the hyperweb. Parameters: v - The specified viewer. o - The specified object. viewExists boolean viewExists(view v) Checks to see if the specified view exists in the hyperweb. Parameters: v - The specified view.

197

Viewers The following operations enable the manipulation of viewers. These operations include the ability to create, delete, edit, and query viewers. addMIMEtype void addMIMEtype(viewerId v, String MIMEtype) Adds the specified MIMEtype to the specified viewer. Indicates that the viewer can manipulate objects of the specified MIMEtype. Parameters: v - The specified viewer. MIMEtype - The supported MIME type. createViewer viewerId createViewer(String viewerName) Creates a new viewer with the specified name, unless this viewer already exists for the active website. In that case, it simply returns the id of the existing viewer. Parameters: viewerName - The name of the viewer. Returns: The id of the newly created viewer, or the id of the previously registered viewer. deleteViewer void deleteViewer(viewerId v) Deletes the specified viewer from the hyperweb. Note: Chimera maintains the consistency of the hyperweb. This operation will delete any views based off this viewer, delete any anchors associated with those views (this includes removing these anchors from any links which contain them) before deleting the viewer. Parameters: v - The specified viewer.

198 getMIMEtypes String[] getMIMEtypes(viewerId v) Retrieves all of the specified viewer's supported MIME types. Parameters: v - The specified viewer. Returns: An array of the viewer's supported MIME types. getViewer viewerId getViewer(String name) Retrieves the viewer with the specified name. getViewerName String getViewerName(viewerId v) Retrieves the name of the specified viewer. Parameters: v - The specified viewer. getViewers viewerId[] getViewers() Retrieves all viewers in the hyperweb. numberOfViewers int numberOfViewers() Retrieves the number of viewers in the hyperweb.

199 setMultipleViews void setMultipleViews(viewerId v, boolean yesOrNo) Specifies whether or not the indicated viewer supports multiple views. Parameters: v - The specified viewer. yesOrNo - A boolean value, TRUE indicates support for multiple views. supportsMultipleViews boolean supportsMultipleViews(viewerId v) Checks to see if the specified viewer supports multiple views. Parameters: v - The specified viewer. supportsType boolean supportsType(viewerId v, String MIMEtype) Checks to see if the specified viewer supports the specified MIMEtype. Parameters: v - The specified viewer. MIMEtype - The specified MIMEtype. viewerExists boolean viewerExists(String name) Checks to see if the specified viewer name exists in the hyperweb. Parameters: name - The name of the target viewer.

200 viewerExists boolean viewerExists(viewerId v) Checks to see if the specified viewer id exists in the hyperweb. Parameters: v - The specified viewer.