Mark Day
John F. Patterson
David Mitchell
Lotus Development Corporation
55 Cambridge Parkway, Cambridge, MA 02142, USA
Mark_Day@lotus.com,
John_Patterson@lotus.com,
Dave_Mitchell@lotus.com
The Notification Service Transfer Protocol (NSTP) is an infrastructure for building synchronous groupware. It is based on the idea of a coordinating notification server that is independent of any given synchronous groupware application. NSTP is intended in some ways to be the synchronous analog of Hypertext Transfer Protocol (HTTP). We describe the features of NSTP, emphasizing similarities and differences with respect to HTTP, and present our rationale for including those features.
In synchronous groupware, two or more people collaborate at what they perceive to be "the same time". Examples of synchronous groupware are chat systems, shared whiteboards, group decision support systems, shared worlds, and collaborative editors. Greif [Greif 88] and Baecker [Baecker 93] have useful background readings on such synchronous groupware. In each such system, the user interfaces of the participants must be kept consistent to promote the impression of working or playing together. Often, the technique for maintaining consistency is specific to the application being implemented. Effectively, each new synchronous groupware application (re)invents some mechanism for achieving consistency. Our approach, the Notification Service Transfer Protocol (NSTP), abstracts out the problem of state consistency from any particular application. It provides a simple, general, open service to support the construction of synchronous groupware.
Each person's actions within the collaboration are mediated by some software system. We refer to the parts of the software system "in front of each person" as the clients. We refer to the persons themselves as users. The clients typically need to coordinate some parts of their state with each other. They achieve this coordination via a notification service, which is implemented by one or more notification servers [Patterson et al. 96]. NSTP [Day et al. 96] is a definition of a particular notification service.
NSTP provides a model in which collaboration-critical shared state is stored at the notification server, where it can be changed by clients. Each change to this shared state causes the server to deliver notifications of the change to interested clients. An unusual aspect of NSTP is that it supports centralized state with decentralized semantics. That is, the server does not understand what the shared state means to the clients; it simply accepts updates to the state and forwards notices of the changes to interested clients.
In this paper, we take three successively-deeper passes at presenting NSTP. In the first pass, we present a concise introduction to the ideas of NSTP and relate it to previous work.
In the second pass, we compare and contrast NSTP with HTTP/1.1 [Fielding et al. 96]. Although the two protocols are used to solve fundamentally different problems, a familiarity with HTTP can help illuminate some of the issues and choices for NSTP.
In the final pass, we discuss interesting features of NSTP, how it has changed since its initial design, and why we made the choices that are embodied in the current protocol.
A notification server's fundamental service is to allow clients to share state and to be notified when that shared state changes. A secondary service, building on the first, is to allow clients to browse among and enter into previously unknown collaborations that use shared state. NSTP uses a model of Things and Places. The shared state is divided into Things, which are contained in Places.
We consider Things first. A Thing is composed of two parts: a mutable value and a small number of immutable attributes that determine how the Thing is treated at the server (for example, under what circumstances it is readable or writable by clients, and under what circumstances notifications should be sent). The value of a Thing may be set to an arbitrary sequence of bytes. In general, the value of a Thing is entirely uninterpreted by the server. A single Thing may thus
A Place is a container of Things. A client can associate itself with a Place, in which case we say that it is in the Place. When a client establishes such an association, it enters the Place; when it removes the association, it leaves the Place. Each Thing is in exactly one Place, and Things cannot be moved from Place to Place. In contrast, a client can be in a number of Places simultaneously, and need not leave one Place to enter another (note that this is an example of a context in which the intuitive notion of a physical Place does not match the semantics of our model).
A Place serves three distinct purposes.
We briefly explain how Places and Things are used for the shared state of a simple but nontrivial example application that implements a shared whiteboard, called Scribble.
Each Scribble client can choose one of a number of drawing and editing tools to modify the shared whiteboard. The shared whiteboard is implemented as a single Place that each client enters. Each distinct drawing object in a shared whiteboard is represented as a Thing in that Place, whose value consists of the information needed to construct the drawing object, such as its type (e.g. oval or rectangle), size, position and color. In addition, there is a shared Thing that encodes the z-order of objects, ensuring that all clients agree on which objects occlude others.
When a client draws a new object, it locks the z-order Thing, creates a new Thing corresponding to the new drawing object, modifies the z-order Thing to include information about the new object, and releases the lock on the z-order Thing. Clients in the Place, including the one making the change, receive a "made" notification for the new Thing (including the value of the new Thing) and a "changed" notification for the change to the z-order Thing (including the new value of that Thing). Clients receiving these notifications modify their display of the shared whiteboard accordingly, displaying the new object in the drawing order specified by the modified z-order.
At this point, we have described as much of our model as is needed to coordinate the shared state of a single known application. But the Web not only allows individual documents to be fetched, but also supports interdocument linking and browsing. Analogously, we want to be able to link Places to each other and traverse those links to enter Places. Since interpreting a Place is the client's responsibility, new types of Places require enhancements to clients. Thus we need a mechanism to dynamically enhance a client to interpret new types of Places.
The elements of a Place that are accessible from outside the Place are said to appear in that Place's Facade. Facades are crucial to our mechanism for browsing Places. A Facade typically contains a Thing that is a description for the Place, allowing a user to decide whether that Place is of interest. In addition, the Facade may contain a Thing whose value is the URL for code to interpret the Place, or whose value is that actual code. In our implementation the code downloaded is Java [Gosling et al. 96][Lindholm and Yellin 96] but we do not depend on any specific Java features in this architecture; a comparable mechanism, albeit with unpleasant security problems, can be built using ActiveX [Microsoft 96a] or similar technologies. A user's Place browser can examine a number of Facades, and upon finding one of interest, the relevant code can be downloaded and executed so as to enter the Place and actually interact with the Things in that Place.
Our work on NSTP starts from three systems: Ubique, Rendezvous, and Thor. NSTP is arguably a reaction to each of these.
Ubique (now Virtual Places, http://www.vplaces.com), introduced a notion of virtual places on the Web. Multiple users at a single Web page could become aware of each other's presence, communicate with each other, and accompany each other on tours to other parts of the Web. NSTP had its origins in a prototype system that demonstrated a Ubique-like interface for Lotus Notes databases rather than Web pages. But having built that prototype, we were interested in what other applications we could build within the same model. In contrast to Ubique, we have chosen to generalize and expose the coordination machinery and protocol so as to allow other applications to be built, rather than trying to sell a particular application and interface.
Rendezvous [Patterson et al. 90] is a toolkit for synchronous groupware; one of us (JFP) was a designer of that system. Rendezvous pointed out the importance of model-view separation in constructing synchronous groupware, and we have carried over that separation into NSTP. However, Rendezvous's internal architecture did not allow for moving the viewing functionality out from the server into the clients, and its performance suffered accordingly. In NSTP, in contrast to Rendezvous, the server is not itself a programmable entity. In addition, the "model" contained in the notification server is only that state required to achieve coordination; we assume that other techniques (files, databases, direct network connections, other servers) will be used to share the full model that might be required by a sophisticated shared application. A further contrast to Rendezvous is that we are attempting to establish interoperability through a protocol, rather than by providing a toolkit. We believe we can more readily achieve widespread interoperability of clients and servers through a network protocol than through a toolkit.
Thor [Liskov et al. 96] is a distributed persistent object system; one of us (MD) was a designer of that system. Because of concerns about integrity of persistent data and security of access, Thor's semantics are inside the system, and Thor includes an entire sophisticated programming language (Theta [Liskov et al. 94]) for the purpose of defining and manipulating the stored objects. Our work on NSTP essentially turns Thor inside out: instead of a persistent object system to which notifications might be added, NSTP is a notification system to which persistence might be added. Since NSTP deals with efficiently transmitting transient state, it is built around a model that is very different from Thor. Instead of a sophisticated server with an embedded object model that logically executes at the server, we have a simple server that does almost nothing and understands almost nothing, simply holding chunks of uninterpreted bits and delivering notifications of changes to those.
Both X Windows [Scheifler and Gettys 86] and HTTP [Fielding et al. 96] have influenced our thinking, both for their technical solutions to problems of networked computing, and for their rapid spread as standards.
The International Telecommunications Union has generated a series of recommendations collectively referred to as T.120 [ITU 95]. The T.120 series is large and complex because it covers a lot of ground (including video conferencing, audio conferencing, and interoperation with ISDN) and because it is the product of a large international telecommunications standards body rather than a small research group. In comparison, NSTP has a modest goal: we want to achieve interoperability and sharing of the coordination component of synchronous groupware applications. NSTP deliberately avoids entanglement with streaming data (audio or video) and persistent data, focusing entirely on the small but important area of sharing coordinating state and notifying clients of changes to that state.
T.120 differs from NSTP in its model of how clients interact. Instead of NSTP's notification server, T.120 uses a model of clients "calling" to establish collaboration. Although T.120 is a standard for "multipoint conferencing", the "multipoint" aspect is built up by bridging together a number of "point-to-point" calls, much as in conventional telephone conference calls. This model works well for two-party collaborations, but it becomes problematic for larger or less tightly-coupled collaborations. In particular, T.120
Server push [Netscape 96] is a technique for sending an arbitrary series of data items from an HTTP server to a client. The server describes the data via its Content-Type as being "multipart/x-mixed-replace." Since the data is multipart, the server can send multiple elements over time. The subtype "x-mixed-replace" indicates that the parts may be of different types, and that a newly received part is intended to replace a previously received part. Fundamentally, however, server push provides only a mechanism for constructing HTTP communication patterns of roughly the form needed for NSTP-like functionality; it does nothing to address the other limitations of HTTP in this problem domain (discussed below in our comparison of HTTP and NSTP).
Other related work falls into one of a few categories:
We have implemented the protocol, a server, a client API layer, an application framework, and a variety of applications. Most of the system has been reimplemented at least once as we have gained experience with the protocol and as new applications have stressed the system in new ways. Our applications have shown the versatility of the protocol: we have built a shared whiteboard, a shared text editor, a Zephyr-like [DellaFera and Eichin 88] message system, a chat room, a few games (such as Go), and a debugging application that displays and manipulates the raw contents of Places. In addition, we have built mechanisms for linking Places to each other, traversing cross-Place links, and downloading Java code to interpret a new Place. Any or all of these applications can run on a single NSTP server without any change to the server, much as a diverse collection of documents can be served up simultaneously by an HTTP server.
Our applications have pointed out limitations that have prompted us to change the protocol. The shared text editor pointed out the need for better performance to support character echoing. The shared whiteboard made clear that we should not pass GIF files through Things, but instead pass URLs to the files on an HTTP server. The message system convinced us that we needed to have some form of multicast messaging independent of changing the state of Things.
Our current implementation is called PlaceHolder. The source and Java class files are available under a no-cost noncommercial license at http://nstp.research.lotus.com.
The previous section summarized the concepts, application, and background of NSTP. In this section, we use HTTP as a point of comparison for NSTP. We see NSTP as in some ways analogous to HTTP, but addressing problems in a different domain. Seen in this light, there are a collection of important similarities and differences between the two protocols.
Like HTTP, NSTP is a simple protocol that is independent of the format of information being sent. Just as HTTP makes no demands about the contents of the pages delivered via the protocol, so NSTP is entirely independent of the content and interpretation of the state that applications use for their coordination. NSTP is also similar to HTTP in its use of URLs to identify entities of interest, and in allowing those URLs to be embedded in the entities of interest. We would argue that much as HTTP is the fundamental ubiquitous plumbing that makes sophisticated document-based Web applications possible, NSTP or something like it should be the fundamental ubiquitous plumbing that makes sophisticated synchronous groupware possible.
However, NSTP is different from HTTP in several important ways:
| NSTP | HTTP | Explanation |
| Creating a Place | POSTing a new document | Creates an association between a URL and a new resource |
| Deleting a Place | DELETEing a document | Removes the association between the URL and a resource, frees storage |
| Examining a Facade | Requesting the HEAD of a document | Provides a small summary of information about a larger entity |
| Entering a Place | GETting a document | Indicates the resource of interest and gets its current state; may set up long-lived connection |
| Leaving a Place | Closing a connection | Ends the delivery of new information |
| Things | HTML fragments | Smaller named entities within larger container. In NSTP, two different clients entering the same Place may receive Things in different orders, which is not typically true of two different HTTP clients receiving fragments in the same document |
| Creating/ deleting/ changing Things | Creating/deleting/changing one or more fragments at once within an existing document | Not actually possible in current HTTP |
| Conventions on Thing usage | HTML | Currently not well-developed. Our current conventions on Thing usage are distinct from NSTP itself. |
The following NSTP capabilities have no plausible analog in HTTP: starting or ending a session with a server; and locking or unlocking a Thing in a Place.
In addition, clients can receive the following kinds of notifications when they are present in a Place, and these have no analog in HTTP: one or more Things have been created; one or more Things have changed; one or more Things have been deleted; the Place has been destroyed.
Having considered the similarities and differences of NSTP and HTTP, we now focus on specific features of NSTP and why they are present.
The design of NSTP adheres to the following principles:
Compared to other systems that support synchronous groupware, our design is unusual in choosing to have centralized state but providing as little processing at the server as possible. We find that centralized state is simpler for any groupware that involves more than two parties, especially if there can be late arrivals to a group already in progress. Indeed, for the class of applications we call "awareness" [Patterson et al. 96], some centralized state representing a group's membership is necessary because the identities of the other parties only become apparent upon joining the group, and members may join or leave at arbitrary times. Even a system such as GroupKit [Roseman and Greenberg 96] that is nominally based entirely on peer-to-peer communication has a centralized portion to deal with awareness. A further advantage of a centralized system is that locking is simpler.
We leave Thing values uninterpreted, and otherwise attempt to minimize server processing for two reasons: scalability and reuse. As noted earlier, the general principle of pushing functionality out to clients whenever possible has been well-established in the distributed systems community [Howard et al. 88]. In addition, we have seen that our minimal constraints on the structure of Things make it easy to adapt a notification server for a wide variety of applications.
All operations refer to at most one Place. A single Place is the largest granularity at which the protocol guarantees consistency, atomicity, and ordering. Our reasoning is that clients needing to coordinate multi-Place actions can do so by means of a distinct Place in which the Things represent the other Places to be coordinated. We avoided any multi-Place messages so that it would be straightforward to use multithreaded structures or multiprocessor machines to implement a server with many Places.
All operations that manipulate Things, except for requesting locks, may deal with multiple Things. We knew that it would be important for performance to allow the batching of multiple requests to the server in a single client message. The current protocol structure allows a single opcode, operating in a single Place, to operate on multiple Things in a single message. We considered allowing multiple opcodes, in a single Place, operating on multiple Things in a single message, but the additional complexity of the protocol structure would be imposed on every request, even the large fraction that would not use it. Following our design principles of keeping things simple and asking clients to pay only for what they use, we rejected more elaborate batching of requests.
By default, all multi-Thing requests are atomic in the narrow sense of being all-or-nothing: if an error occurs partway through a multi-Thing request, none of the request's effects take place, and no request can ever see partial effects from another request. Although this requirement makes servers somewhat more difficult to implement, it is vital that participants in a synchronous collaboration have a consistent view of the shared state despite failures or errors.
We made attributes immutable. In addition to eliminating complexity from the protocol and server, making attributes immutable allows a number of implementation efficiencies at the server, which can be written with the knowledge that attributes cannot be modified after a Thing has been created. The only part of a Thing that is mutable is its value.
We initially thought that attributes would be mutable as well. However, we quickly realized that the server would need to deliver notifications when attributes changed; there would need to be additional attributes that allowed some Things to suppress those notifications; there might need to be one additional kind of notification for attribute changes (or, then again, perhaps attribute changes were the same kind of change as value changes); and mutable attributes didn't seem to be very important.
In our experience to date, the immutability of attributes has not imposed any special burden on the applications we have built.
NSTP uses specialized Things as the mechanism to control the behavior of Places and to provide information about Places. Each Place has a collection of predefined Things for items such as the name of the Place or the list of Things in the Place. By treating these system-related entities as special Things instead of additional messages, we reduce the amount of implementation effort required to bring up a minimal client: the same mechanisms used to examine and change user-defined Things can be used to control the behavior of Places. One particular predefined Thing is of some interest: the user-Thing is automatically created by the server in a Place when a client enters that Place, and is automatically deleted by the server when the client leaves that Place. Its presence or absence thus serves as a reliable indication of the corresponding client's presence or absence. The value of the user-Thing is not controlled by the server, and is writable by the appropriate client. Our applications have typically used the user-Thing value to store contact information for the client's user, but other uses are possible; for example, a rudimentary chat system can be built if clients simply modify their user-Thing values to contain their current text to be sent, and display to the user any changes in other user-Thing values.
There are a number of ways to have Places implicitly destroyed: the two we use most often are "never" (meaning that the Place must be explicitly destroyed) and "when last user leaves". To help the server clean up after itself, we would like to create Places so that they are destroyed implicitly unless clients specifically request otherwise. We found that a satisfactory solution to this requires a slightly unusual semantics for Place creation. When a new Place is created, the creating client is immediately inside the Place; that is, the Place is effectively created "around" the creator. The creator's presence ensures that the Place is not immediately destroyed, and the creator's departure (explicitly, or implicitly when their connection to the server breaks) causes the Place's destruction unless the Place's destruction policy has been changed or another client has entered the Place.
Our initial authentication scheme involved a specific two-message login sequence that we believed would be adequate. On further examination, we realized that this would be overkill for some logins and completely inadequate for others. Rather than embedding a particular authentication regime in the protocol, we changed our authentication model to allow an arbitrary number of exchanges. There is now a single INIT message, which contains a field indicating the authentication protocol and some data. The server can accept the login (returning OK), can reject the login (sending an error message), or challenge the login, sending back a message that contains some data that is intended to be meaningful within the authentication protocol. The client then incorporates the data from the challenge into a new INIT message that it sends to the server, where it is (again) accepted, rejected, or challenged.
Initially we were quite insistent that the role of a notification server was to share state, albeit ephemeral state, in distinction to multicast services such as Zephyr [DellaFera and Eichin 88]. Over time, we have come to realize that shared state notification and multicasting of messages are complementary, and that forcing multicasting into a framework of shared state is unpleasant. Accordingly, we added notices to the protocol. A broadcast notice is sent to every client present in a given Place; a targeted notice is sent to a specific client, as long as that client is present in the Place. Both kinds of notice are treated as notifications in terms of the protocol. With the addition of notices, we were able to eliminate a category of message called alerts, which had been defined for the purpose of conveying server-related information to clients. The addition of notices has opened a rich collection of possibilities for controlling and communicating with the server, since the sender or recipient of such a notice can be a pseudo-user actually representing some part of the server.
We will continue to refine our implementation based on experience with the protocol, both ours and the people who have downloaded our system. In addition to general improvements to the robustness of our implementation, we also plan to do performance studies to understand how well the system scales.
We hope to convene a working group under the auspices of the World Wide Web Consortium to explore the requirements for construction of synchronous groupware. We would expect such a working group to provide a forum for our group and other interested parties to discuss the merits and limitations of protocols such as NSTP and whether such a protocol is a suitable basis for a draft standard.
The authors gratefully acknowledge the contributions of Quinton Zondervan, Chris Lopes, and Kenneth Pang.
[Baecker 93] Baecker, R.M. (Ed) Readings in Groupware and Computer-Supported Cooperative Work: Assisting Human-Human Collaboration. Morgan Kaufmann Publishers, San Mateo, CA 1993.
[Bentley et al. 95] Bentley, R., T. Hostmann, K. Sikkel, and J. Trevor. "Supporting Collaborative Information Sharing with the World Wide Web: The BSCW Shared Workspace System." Proceedings of Fourth World Wide Web Conference. http://www.w3.org/pub/WWW/Journal/1/bentley.151/paper/151.html
[Ciancarini et al. 96] Ciancarini, P., A. Knoche, R. Tolksdorf, and F. Vitali. "PageSpace: An Architecture to Coordinate Distributed Applications on the Web." Proceedings of the Fifth International World Wide Web Conference. http://www5conf.inria.fr/fich_html/papers/P5/Overview.html
[Day et al. 96] Day, M., J.F. Patterson, J. Kucan, W.M. Chee, and D. Mitchell. "Notification Service Transfer Protocol (NSTP) version 1.0." Lotus Workgroup Technologies Technical Report 96-08.
[DellaFera and Eichin E88] DellaFera, C.A. and Eichin, M.W. "The Zephyr Notification Service." Proceedings of the USENIX Winter Conference, Dallas TX: USENIX Association, 1988.
[Fielding et al. 96] Fielding, R., J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1." Internet Draft (work in progress). See http://www.w3.org/pub/WWW/Protocols/Specs.html#HTTP1.1
[Frivold et al. 94] Frivold, T.J., R.E. Lang, and M.W. Fong. "Extending WWW for Synchronous Collaboration." Second World Wide Web Conference '94: Mosaic and the Web. http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/CSCW/frivold/frivold.html.
[Gosling et al. 96] Gosling, J., B. Joy, and G. Steele. The Java Language Specification. Addison-Wesley, Reading, MA 1996.
[Greif 88] Greif, I. (Ed) Computer-Supported Cooperative Work: A Book of Readings. Morgan Kaufmann Publishers, San Mateo, CA, 1988.
[Howard et al. 88] Howard, J.H., M.L. Kazar, S.G. Menees, D.A. Nichols, M. Satyanarayanan, R.N. Sidebotham, and M.J. West. "Scale and Performance in a Distributed File System." ACM Transactions on Computer Systems, 6(1):51-81, February 1988.
[Hurwitz and Mallery 95] Hurwitz, R., and J.C. Mallery. "The Open Meeting: A Web-Based System for Conferencing and Collaboration." Proceedings of Fourth World Wide Web Conference. http://www.w3.org/pub/WWW/Journal/1/hurwitz.349/paper/349.html
[ITU 95] International Telecommunication Union. Data Protocols for Multimedia Conferencing. ITU-T Recommendation T.120 (1995). International Telecommunication Union, Bern, Switzerland. http://www.itu.ch
[Liskov et al. 96] Liskov, B., A. Adya, M. Castro, D. Curtis, M. Day, R. Gruber, S. Ghemawat, A.C. Myers, and L. Srira. "Safe and Efficient Sharing of Persistent Objects in Thor.". ACM 1996 Conference on Management of Data (SIGMOD).ftp://ftp.pmg.lcs.mit.edu/pub/thor/thor.ps
[Liskov et al. 94] Liskov, B., D. Curtis, M. Day, S. Ghemawat, R. Gruber, P. Johnson, A.C. Myers. "Theta Reference Manual." Programming Methodology Group Memo 88, MIT Laboratory for Computer Science. http://www.pmg.lcs.mit.edu/papers/thetaref/index.html
[Lindholm and Yellin 96] Lindholm, T., and F. Yellin. The Java Virtual Machine Specification. Addison-Wesley, Reading, MA 1996.
[Microsoft 96a] Microsoft Corporation. "Frequently Asked Questions about ActiveX Controls."http://www.microsoft.com/intdev/controls/ctrlfaq.htm
[Microsoft 96b] Microsoft Corporation. "Microsoft NetMeeting." http://www.microsoft.com/netmeeting
[Najork and Brown 96] Najork, M.A., and M.H. Brown. "Distributed Active Objects." Proceedings of the Fifth International World Wide Web Conference. http://www5conf.inria.fr/fich_html/papers/P13/Overview.html
[Netscape 96] Netscape Corporation. "An Exploration of Dynamic Documents." http://home.netscape.com/assist/net_sites/pushpull.html
[Palfreyman and Rodden 96] Palfreyman, K., and T. Rodden. "A Protocol for User Awareness on the World Wide Web." ACM 1996 Conference on Computer Supported Cooperative Work, pages 130-139. http://www.comp.lancs.ac.uk/computing/users/kev/papers/CSCW96
[Patterson et al. 96] Patterson, J.F., M. Day, and J. Kucan. "Notification Servers for Synchronous Groupware." ACM 1996 Conference on Computer Supported Cooperative Work, pages 122-129. http://www.lotus.com/research/2166.htm
[Patterson et al. 90] Patterson, J.F., Hill, R.D., Rohall, S.L., and Meeks, W.S. "Rendezvous: An Architecture for Synchronous Multi-User Applications." ACM 1990 Conference on Computer Supported Cooperative Work, pages 317-328.
[Roseman and Greenberg 96] Roseman, M. and S. Greenberg. "Building Real Time Groupware with GroupKit, A Groupware Toolkit." ACM Transactions on Computer Human Interaction, March 1996. http://www.cpsc.ucalgary.ca/projects/grouplab/papers/groupkit-tochi95.ps
[Satyanarayanan 92] Satyanarayanan, M. "The Influence of Scale on Distributed File System Design." IEEE Transactions on Software Engineering 18(1):1-8, January 1992.
[Scheifler and Gettys 86] Scheifler, R., and J. Gettys. "The X Window System." ACM Transactions on Graphics 5(2):79-109, April 1986.
[Trevor et al. 96] Trevor, J., R. Bentley, and G. Wildgruber. "Exorcising daemons: A modular and lightweight approach to deploying applications on the Web." Proceedings of the Fifth International World Wide Web Conference. http://www5conf.inria.fr/fich_html/papers/P14/Overview.html
[Vitali and Durand 95] Vitali, F., and D.G. Durand. "Using Versioning to Support Collaboration on the WWW." Proceedings of Fourth World Wide Web Conference. http://www.w3.org/pub/WWW/Journal/1/vitali.190/paper/190.html
[Wittenburg et al. 95] Wittenburg, K., D. Das, W. Hill, and L. Stead. "Group Asynchronous Browsing on the World Wide Web." Proceedings of Fourth World Wide Web Conference. http://www.w3.org/pub/WWW/Journal/1/wittenburg.098/paper/098.html
[Woo and Rees 94] Woo, T.K. and M.J. Rees. "A Synchronous Collaboration Tool for World-Wide Web." Second World Wide Web Conference '94: Mosaic and the Web. http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/CSCW/rees/SynColTol.html..
[Yeh et al. 96] Yeh, P.-J., B.-H. Chen, M.-C. Lai, S.-M. Yuan. "Synchronous Navigation Control for Distance Learning on the Web." Proceedings of the Fifth International World Wide Web Conference. http://www5conf.inria.fr/fich_html/papers/P28/Overview.html
Lotus Notes is a registered trademark of Lotus Development Corporation.