A High-Level and Flexible Framework for Implementing ... - CiteSeerX

A High-Level and Flexible Framework for Implementing Multi-User User-Interfaces PRASUN DEWAN RAJIV CHOUDHARY Purdue University

We have developed a high-level and flexible framework for supporting the construction of multi-user user-interfaces. The framework is based on a generalized editing interaction model, which allows users to view programs as active data that can be concurrently edited by multiple users. It consists of several novel components including a refinement of both the Seeheim UIMS architecture and the distributed graphics architecture that explicitly addresses multi-user interaction; the abstractions of shared active variables and interaction variables, which allow users and applications to exchange information; a set of default collaboration rules designed to keep the collaboration-awareness low in multiuser programs; and a small but powerful set of primitives for overriding these rules. The framework allows users to be dynamically added and removed from a multi-user session, different users to use different user interfaces to interact with an application, the modules interacting with a particular user to execute on the local workstation, and programmers to incrementally trade automation for flexibility. We have implemented the framework as part of a system called Suite. This paper motivates, describes, and illustrates the framework using the concrete example of Suite, discusses how it can be implemented in other kinds of systems, compares it with related work, discusses its shortcomings, and suggests directions for future work. Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distributed Systems—distributed applications, distributed databases; D.2.2 [Software Engineering]: Tools and Techniques—user interfaces; D.2.6 [Software Engineering]: Programming Environments—interactive; D.3.3 [Programming Languages]: Language Constructs—input/output; H.1.2 [Models and Principles]: User/Machine Systems—human factors; H.4.1 [Information Systems Applications]: Office Automation; I.7.1 [Text Processing]: Text Editing General Terms: Design, Human Factors, Languages Additional Key Words and Phrases: computer supported cooperative work, groupware, editing, user interface management systems

1. Introduction Modern powerful bitmapped workstations connected by high-speed networks offer the opportunity to build interactive programs supporting collaboration among multiple, possibly geographically dispersed users. It is easy to imagine a variety of such programs including a debugger allowing multiple programmers to debug a program together; a budget spreadsheet allowing multiple managers to balance a budget; a project management tool allowing

Authors’ address: Department of Computer Sciences, Purdue University, W. Lafayette, IN 47907. This research was supported in part by National Science Foundation grant IRI-9015442 and in part by a grant from the Software Engineering Research Center at Purdue University, a National Science Foundation Industry/University Cooperative Research Center (NSF Grant No. ECD-8913133).

P. Dewan and R. Choudhary

Implementing Multi-User Interfaces

2

different members of a project team to display and modify the status of a project; a program demonstrator allowing one or more users to demonstrate a program to a group of users; a browser allowing a teacher to browse through a text-book with a group of students; and a design tool allowing several designers to compose a design document. Multi-user programs such as these have the potential of automating a significant amount of cooperative work carried out at current organizations [8]. While the potential benefits of multi-user programs have been known for some time [20, 48], few multi-user programs have been developed so far. A reason for the current lack of such programs is that their user-interfaces are difficult to implement. Like single-user user-interfaces, these user-interfaces must perform several interaction tasks such as displaying data, parsing input, and reporting errors, which are code intensive [55]. In addition, they must perform several collaboration tasks such as dynamically making and breaking connections with (possibly remote) users, multiplexing input from and demultiplexing output to multiple users, informing users of input entered by other users, helping users coordinate their interaction, and providing concurrency and access control [19, 48]. As a result, even the simplest of multi-user programs, such as a two-person talk program, require substantial code. The idea of providing high-level and flexible support for the implementation of the user interfaces of these programs is, therefore, attractive. This idea requires the design of an application-independent model of multi-user interaction together with a high-level and flexible framework for supporting the model. Recent work in single-user user interface design [1, 11, 23, 40, 50] has shown that single-user editing can be used to model the user interfaces of a large variety of contemporary single-user interactive programs including spreadsheets, language-oriented editors, form editors, document editors, machine-language interpreters, command interpreters, and debuggers. Moreover, recent work in single-user user-interface generation [11] has shown that it is possible to design a high-level and flexible framework for supporting the model. We have extended these works by using editing as a basis for a high-level and flexible framework for supporting the implementation of multi-user programs. The framework has several novel concepts: User Interface Architecture: It supports a new user interface architecture, which is a refinement of both the Seeheim user interface architecture [43] and the distributed graphics architecture [27, 31] adapted to explicitly address multi-user interaction. Like the Seeheim architecture, our architecture divides an interactive program into an application object, which defines the functional core of the program, and a UIMS (User Interface Management System), which manages the user-interface of the program. In addition, it divides the UIMS into multiple dialogue managers, each of which manages the interaction between a particular user and the program. Furthermore, like the distributed graphics architecture, it allows an interactive component (a dialogue manager) to execute on the local host. Shared Active Variables and Interaction Variables: It supports the new abstractions of shared active variables and interaction variables, which allow application objects and users to communicate with each other. These abstractions are extensions of existing abstractions supported by single-user frameworks— a shared active variable is an active variable [28] that can be displayed to and manipulated by multiple users via interaction variables and an interaction variable is an interaction object [51] automatically created for a user by the framework



3

that can be coupled with corresponding interaction variables created for other users. Incremental Collaboration Awareness: It offers a default collaboration scheme for supporting ‘‘collaborationtransparent programs’’ [33], that is, programs that are completely unaware that they are interacting with multiple users. Moreover, it offers flexible primitives that support ‘‘collaboration-opaque programs’’, that is, programs that completely override the default collaboration scheme. More importantly, it offers a small and powerful set of constructs controlling different aspects of collaboration that offer collaboration-aware programs several intermediate points between complete collaboration-transparency and collaboration-opaqueness. As a result, it allows them to incrementally trade automation for flexibility and tailor only those aspects of the default collaboration scheme that are necessary to offer the desired collaboration scheme. The framework is an extension of the single-user framework developed as part of the work on single-user Suite [9], which provides high-level and flexible support for implementing single-user, editor-based user-interfaces. We have implemented the framework on top of single-user Suite, thereby developing a new system, called multi-user Suite, for supporting the development of multi-user, editor-based programs. In this paper, we focus only on the extensions to the single-user framework supported by single-user Suite. We use the concrete example of multi-user Suite to describe these extensions. We do not describe all of our current extensions to single-user Suite — we describe only a subset of these extensions which defines a basic framework to which other extensions are being added. In particular, we do not report our ongoing works on parameterized coupling, concurrency control, access control, and undo/redo models, which are based on the framework described here. A brief description of preliminary versions of some of the concepts described here has appeared in a conference publication [12]. A brief description of a preliminary version of our parameterized coupling model is given in [13]. The remainder of this paper is organized as follows. Section 2 describes the collaboration functions, issues, and requirements addressed by our work. Section 3 gives an overview of single-user Suite. Section 4 is the major portion of the paper. We motivate and describe the major components of our design and show how a single-user editing system such as single-user Suite is extended to support multi-user interaction. Section 5 describes the implementation of the design in multi-user Suite. Section 6 shows how Suite can be used to implement different classes of multi-user applications. Section 7 compares our approach with shared window systems and other related work. Section 8 discusses how our approach can be used to extend single-user systems other than editing systems. Finally, Section 9 summarizes our results and discusses potential directions for future work. 2. Collaboration Functions, Issues, and Requirements Collaboration Functions A large number of functions must be performed to support a multi-user interface. All functions such as presentation and control functions [43] that need to be performed to support a single-user interface must also be performed to support a multi-user interface, since the former is a special case of the latter. In addition, several functions must be performed to allow multiple users to use an interface [19, 48]. We refer to the former as interaction functions and the latter as collaboration functions. In this paper, we address only collaboration functions. We assume that a multi-user framework is designed by extending a single-user framework, called its basis, which supports the



4

interaction functions. We address the following specific collaboration functions: connecting/disconnecting users — connecting/disconnecting users and multi-user programs, demultiplexing I/O calls — directing I/O calls at multiple users, multiplexing input — gathering input from multiple users, access control — allowing only authorized users to execute a command offered by a multi-user program, coupling — informing a user of an input value entered by another user, concurrency control — preventing users from entering conflicting input values, collaboration-awareness in the user interface — displaying information and offering commands that allow users to coordinate their activities with each other, forking programs — invoking (single-user or multi-user) programs from a multi-user session. This is not a complete list of collaboration functions, which is still a subject of research. Two important collaboration functions beyond the scope of this paper are multi-user undo/redo [5] and multi-user, multi-media support [3]. Collaboration Issues Four important issues arise in the design of a framework supporting collaboration functions of a multi-user program: Basis: What kind of single-user framework should be used as the basis for the multi-user framework? Multi-User Architecture: What kind of architecture should be supported by the framework? Specifically, what kind of modules should be supported by the framework, in which processes should they execute, on which hosts of a distributed system should they execute, and what should be their environments?1 Multi-User Abstractions: What kind of data structures should be supported to allow users and programs to communicate with each other? Multi-User Programming- and User-Interface: What kind of programming- and user-interface should be provided to allow programs and users, respectively, to manipulate these abstractions? Collaboration Requirements There are several approaches to resolving each of these issues. For instance, it is possible to use as a basis a variety of single-user frameworks ranging from low-level window systems such as X [49] to high-level editing systems such as Dost [11] and Workspaces [29]. Therefore, it is important to identify a set of collaboration requirements to resolve the design choices. We have identified the following collaboration requirements based on our experience with developing and using a variety of multi-user programs: 1 We use the term ‘‘environment’’ to refer to properties such as the display, printer and search-paths of a user session that are maintained by the operating system and inherited by programs invoked from that session. A more precise definition of this term must be relative to the underlying operating system. Multi-user Suite, which is implemented on the UNIX operating system, uses the UNIX definition of this term.



5

Dynamic Binding: The framework should allow a user to be dynamically added to or removed from a multiuser session created for a multi-user program, thereby allowing busy users to participate in a multi-user session only during the phases in which they are needed. User-Interface Independence: The framework should allow different users of a program to use different user interfaces2 to interact with a program. In particular, it should allow users to (a) see different screen images, thereby allowing them to, for instance, scroll to different parts of a document; (b) have different access rights, thereby supporting roles [42]; (c) have different sets of locks, thereby supporting concurrency control; and (d) interact using different environments, thereby allowing users using different workstations and file systems to collaborate with each other. Concurrent Scheduling: The framework should allow the modules interacting with different users to be scheduled independently, thereby preventing these modules from starving each other and allowing them to execute concurrently on a multiprocessor. Error Independence: A local user-interface error, that is, execution of an erroneous command whose results are not shared with other users, should not cause failures in the connections between other users and the program. Flexible Placement: In a distributed multi-user session, users should have the flexibility of choosing where the modules that implement their user interfaces execute. In particular, they should have the flexibility of placing them on their local workstations, thereby getting local response. Collaboration Transparency: The framework should support collaboration-transparent programs [33], that is, programs that are unaware that their instances can interact with multiple users. By supporting such programs, the framework can offer automation of collaboration functions supported by it, since these programs contain no code for specifying multi-user aspects of the interaction. Similarly, it should also support collaborationtransparent user-interfaces, that is, multi-user user-interfaces that do not display any information or require the use of any command that is not useful in the single-user case. By supporting such user interfaces, the system can support multi-user programs without increasing the overhead of using these programs. In particular, it can make a single user of a multi-user program completely unaware that he is interacting with a multi-user program. Collaboration Awareness: The framework should also support collaboration-aware programs, thereby allowing programs to exercise control over the way their collaboration tasks are performed. Similarly, it should support collaboration-aware user-interfaces. Incremental Awareness: The framework should allow collaboration-transparent programs and user-interfaces to be easily and incrementally transformed to collaboration-aware programs and user-interfaces by supporting 2 In this paper, we use the term use-interface in three different but related ways. By the user-interface of a user, we mean the user-interface offered to a particular user of a program; by the user-interface of a multi-user program, we mean the combined user-interfaces of the individual users of the programs; and by the user-interface of Suite we mean those aspects of the user-interfaces of Suite multi-user programs that are common to these programs. These usages are consistent with popular usages of this term.



6

both high-level specification and low-level implementation of the various collaboration tasks of a program. Compatibility: The framework should allow instances of programs developed using the basis to be used by multiple users, thereby promoting reuse of existing programs. Moreover, the behaviors of instances of programs created using the single-user basis and the multi-user framework should be identical when they are used by single users. We have designed an approach for meeting these requirements. We describe first the basis of our approach and then how we have extended the basis to support multi-user interaction. 3. Basis It is possible to use as a basis a variety of single-user frameworks including conventional programming languages such as Pascal, window systems such as X [49], toolkits such as Interviews [34], and high-level, specification-based systems, such as UIDE [22] and SERPENT [2], which include a model of application data. Our choice of the basis was constrained by our requirements. In particular, the requirement of user-interface independence implies that the framework must support sharing of application data without sharing of the user-interfaces to manipulate them, thereby implying the use of a basis that understands application data. Only high-level, specification-based systems satisfy this requirement. For this reason, we chose single-user Suite, a representative of this class of systems, as the basis of our multi-user framework. This implies that multi-user Suite cannot directly support multi-user versions of single-user interfaces that have not been or cannot be created by single-user Suite. In particular, it cannot directly3 support multi-user versions of arbitrary existing X-based user-interfaces or arbitrary graphical user interfaces, which currently cannot be supported by single-user Suite. Single-user Suite4 is the successor of Dost [11], a system developed by the first author as part of his dissertation work at the University of Wisconsin. We give here a brief summary of the main concepts used in the design of the system. More detailed descriptions of these concepts and motivation for supporting them are given in papers on single-user Suite [9, 10, 14] and Dost [11]. We also introduce in this section a running example, which is used to motivate and illustrate the concepts used in the design of both single-user and multi-user Suite. (Single-user) Suite differs from traditional interactive environments in several important ways. Users of Suite do not ‘‘run’’ programs to create temporary processes; instead they instantiate them to create persistent, large-grained objects. An object has a network-wide file name, executes in its own address space, can perform arbitrary computations written in a conventional programming language, and can respond to messages from other, possibly remote, objects [10]. A user can connect/disconnect a dialogue manager to it to start/terminate an interactive session with it. A dialogue manager corresponds to a UIMS in the Seeheim reference model [43], and implements the user interface of the object. It is provided by the system and offers textual and simple graphical user-interfaces to interact with an 3 4

It is possible to use it indirectly for creating multi-user versions of single-user interfaces developed using other systems, as shown in §6.

By single-user Suite, we mean the version of Suite that supports single-user programs. The system does support the creation of multi-user applications consisting of communicating, single-user programs, as shown in [9].



7

object. It is itself an object and can be connected by the user to a dialogue manager. In the rest of the paper, we will refer to an object connected to a dialogue manager as an application object or simply an application when we need to distinguish it from the dialogue manager. Suite offers programmers several abstractions for defining the user interface of an object. These abstractions include active variables, interaction variables, attributes, value groups, and object windows. An active variable is an application variable whose value is displayed to the user and can be changed by him via an interaction variable. An interaction variable is a user’s local version of an active variable of an object, which is created when the user connects to the object. It can be updated by the object to show a result, edited by the user to input a new value, and committed by the user to update the value of the corresponding active variable. An attribute is an interaction property of an interaction variable, which can determine, for instance, the presentation of the variable or the callbacks invoked when it is edited by the user [9]. A value group is a group of related interaction variables that stores attributes shared by these variables. An inheritance relation is defined among value groups that allows a more specific value group to inherit attributes from a more general one [14]. An object window is a rectangular area on the screen that displays textual or graphical presentations of interaction variables. We refer to interaction variables, attributes, value groups, and windows as interaction entities, since they are created for interacting with users. All interaction entities created for interacting with a user are managed by the dialogue manager of the application.5 Dialogue managers offer application objects and users a procedural and user interface, respectively, to create and manipulate interaction entities. The procedural interface consists of Suite calls, which are procedures invoked by objects in dialogue managers to perform operations on interaction entities, and Suite callbacks, which are procedures invoked by dialogue managers in applications in response to user actions.6 Suite calls consist mainly of: Creation/Deletion Calls: These calls allow applications to create/delete displays of interaction variables and include

the

Dm_Submit/Dm_Remove7

calls,

which

create/delete

interaction

variables,

the

Dm_Engage/Dm_Engage_Specific calls, which create displays of these data structures in an anonymous/named object window, and the Dm_Disengage call, which deletes these displays. Attribute Setting/Retrieving Calls: These calls consist of the Dm_SetAttr and Dm_GetAttr calls, which define and retrieve, respectively, the value of an attribute in a value group. Value Setting/Retrieving Calls: These calls include the Dm_Update and Dm_GetValue calls, which update and retrieve, respectively, the value of an active variable, and the Dm_SequenceElementAppend, Dm_SequenceElementInsert, and Dm_SequenceElementDelete calls, which append, insert, and delete, respectively, a sequence element. 5 Interaction entities are light-weight objects in some other systems such as Interviews [34], GWUIMS [51], Colab [53], and Rendezvous [41] and are therefore called interaction objects [51] in some of these systems. However, in Suite they are represented by conventional data structures within heavy-weight objects. 6

Of course, from a dialogue manager’s (server’s) point of view, a callback invoked in the application is a call and a call invoked by the application is a callback. In this paper, we take the application’s (client’s) point of view. 7

Suite calls are prefixed with Dm since they are executed by dialogue managers.



8

Message Call: The Dm_Message call displays a text message to the user. A Suite call made when the application is not connected to a dialogue manager is a no-op. The Suite callbacks inform the application of actions performed by the user. They consist mainly of the load callback, which is invoked when the user starts an editing session with the application, an optional unload callback, which is invoked when the user terminates an editing session with the application, validate callbacks, which check user changes to interaction variables for semantic consistency, and update callbacks, which are invoked when the user commits semantically correct changes. A dialogue manager displays several windows including one or more object windows defined by the application for displaying interaction variables, a menu window for invoking commands, an error window for displaying error reports, and a message window for displaying messages. The user can choose which of these windows are mapped to the screen. The dialogue manager provides a structure-editing interface to edit interaction variables. We illustrate the user- and procedural-interfaces to Suite abstractions using the example of the Suite program budget_example, which is an editor of a budget. A user can use the command budget_example -name my_budget & to create a new instance, called my_budget, of the program. Later, the same or a different user can use the command dm -name my_dm -load my_budget & to create a new dialogue manager, called my_dm and connect it to the newly created application. The dialogue manager creates two object windows, budget and comments, for displaying the active variables of the application. It displays in the object window budget, the budget managed by the application, and in the object window, comments, a placeholder for the description of the application and a list of comments on modifications to the budget. The user can select the placeholder to display the application description in a gnumacs window (Figure 1). Moreover, he can make one or more changes to these data structures, such as a change to the

Figure 1: Single-User Interaction



9

Salary and Travel fields of the budget (Figure 1), and later commit these changes by executing the accept command in the menu window. The application responds to the commitment of the changes by recomputing the budget and updating its display on the screen (Figure 2). Figure 3 shows the main components of the program budget_example. The first line of the program is a special C comment telling Suite the types of the active variables of the program. The Load procedure is the callback invoked by a dialogue manager when the user starts a session with the application. It makes several Suite calls to define the nature of the session. It invokes Dm_Submit to create the interaction variables ExampleBudget, ExampleComments, and ExampleDescription, in the dialogue manager. The arguments of Dm_Submit specify the location, name, and type, respectively, of the associated active variable. It invokes several Dm_SetAttr calls to define attributes of value groups. The first Dm_SetAttr call defines the update callback for a value of type Budget, which updates the dependent fields of the value and invokes Dm_Update to refresh the display of the value. The second Dm_SetAttr call defines the select callback of the variable, ExampleDescription, which is invoked when the user selects the value. This procedure invokes an operating system command to display a description of the budget. Both callbacks take two arguments, the first is the name of the interaction variable that was modified/selected and second is a pointer to the value of the variable. The last Dm_SetAttr call tells Suite that integer values should be displayed as scrollbars. Finally, the load callback invokes the Dm_Engage calls to ask Suite to display ExampleBudget in the graphics window budget, and ExampleDescription and ExampleComments in the text window comments. Single-user Suite allowed only one user to interact with a particular application at any one time. In the next section, we describe how we have used it as a basis for a multi-user framework that satisfies the requirements of §2. While we illustrate our multi-user framework using the example of single-user Suite, it can be built on any basis that supports the concepts of: active variables and attributed interaction variables,

Figure 2: The User Commits Changes



10

/*dmc Editable Budget */ #define OVERHEAD 0.51 typedef struct { int Salary, Travel, Equipment; int IndirectCosts, Total; } Budget; String ExampleDescription; StringSeq ExampleComments; Budget ExampleBudget; void UpdateBudget(name, val) char *name; Budget *val; { #ifdef DEBUG Dm_Message("UpdateBudget Starts"); #endif val->IndirectCosts = (val->Salary + val->Travel) * OVERHEAD; val->Total=val->Salary+val->Travel+val->Equipment+val->IndirectCosts; ExampleBudget = *val; Dm_Update ("ExampleBudget", "Budget", val); #ifdef DEBUG Dm_Message("UpdateBudget Terminates"); #endif } void DescribeApp (name, val) char *name; Budget *val; { system ("gnumacs README &"); } Load () { Dm_Submit (&ExampleBudget, "ExampleBudget", "Budget"); Dm_Submit (&ExampleDescription, "ExampleDescription", "String"); Dm_Submit (&ExampleComments, "ExampleComments", "StringSeq"); Dm_SetAttr ("Type: Budget", AttrUpdateProc, UpdateBudget); Dm_SetAttr ("Value: ExampleDescription", AttrSelectProc, DescribeApp); Dm_SetAttr ("Type: int", AttrWidget, AttrHorizontalScrollbar); Dm_Engage_Specific ("ExampleBudget", "budget", "Graphical"); Dm_Engage_Specific ("ExampleDescription", "comments", "Text"); Dm_Engage_Specific ("ExampleComments", "comments", "Text"); }

Figure 3. Single-User/Collaboration-Transparent Program user-interface commands to initiate/terminate sessions and edit/commit values of interaction variables, callbacks to inform applications about user invocation of these commands, calls to create/delete interaction variables, set/retrieve their values and attributes, and display messages. Our approach is independent of the exact set of types of the active variables and interaction variables, attributes of interaction variables, user-interface commands, and calls and callbacks supported by the basis. We have given in this section some of the details of Suite to show in later sections concrete examples of multi-user programs. While other frameworks have some of these properties, to the best of our knowledge, the editor-based systems, Dost and single-user Suite, are the only single-user frameworks that have all of these features. However, parts of our approach can be be applied to single-user frameworks that do not satisfy some of the these properties, as discussed in Section 8.



11

4. Multi-User Framework Our multi-user framework allows multiple users to concurrently edit an object. We refer to such an object as a multi-user object, and the program executed by it as a multi-user program. Strictly speaking, our extensions support ‘‘multi-session’’ objects and programs rather than ‘‘multi-user’’ objects and programs since a user can simultaneously start multiple editing sessions with an object. However, in the rest of the paper, we will use the terms ‘‘user’’ and ‘‘session’’ interchangeably unless we need to explicitly distinguish between them. We describe below the three major components of the framework: a multi-user architecture, a set of variable-grained abstractions for allowing users and a multi-user object to communicate with each other; and a programming- and user-interface, which allow programs and users, respectively, to manipulate these abstractions. Sections 4.1 and 4.2 describe the multi-user abstractions and architecture, respectively, and Sections 4.3 and 4.4 discuss the multi-user programming and user interfaces. Section 4.3 describes the parts of these interfaces that support collaboration-transparency and compatibility and Section 4.4 describes the parts that support collaboration awareness. 4.1. Multi-User Abstractions The abstractions supported by multi-user Suite are direct extensions of corresponding abstractions supported by single-user Suite. They include the abstraction of a shared active variable, which is an application variable that can be displayed to and modified by multiple users. As in single-user Suite, users do not directly view and modify the values of active variables. Instead, they view and modify values of interaction variables, which can be updated by the application. Moreover, as in single-user Suite, interaction variables are grouped into value groups whose attributes determine format, view, and other interaction properties of these variables. Finally, multi-user Suite creates object, message, and other single-user Suite windows for users of multi-user applications and provides them with commands to manipulate interaction variables, value groups, and windows. One approach to defining the sharing semantics of these interaction entities is to create a single logical set of interaction variables, value groups, and windows for all users of an application8. However, this approach is not consistent with the requirement of user-interface independence since it forces all users to share a single interaction state. Therefore, our framework creates separate logical sets of interaction entities for different users of an application. In particular, it creates separate interaction variables for users sharing an active variable (Figure 4), thereby allowing them to independently edit their values. Similarly, it creates a separate set of value groups (and associated attributes) for each of the users of an application, thereby allowing them to independently define formats, views, and other interaction properties of interaction variables; and also a separate set of windows for each of these users, thereby allowing them to independently set size, position, and other interaction properties of their windows.

8 Naturally, the windows would have to be physically replicated on the workstations of its users. Other interaction entities could also be physically replicated to support caching.



12

Editable Object Shared Active Variable Dm_SetAttr Dm_SetGrpAttr Dm_SetAttr_Current

Dm_SetAttr Dm_SetGrpAttr Dm_SetAttr_Current ValidateCallback UpdateCallback Dialogue Manager

Interaction Variable

Coupling

ValidateCallback UpdateCallback

Dialogue Manager

User 1

Interaction Variable

User 2 Figure 4: Multi-User Suite

Our approach of creating separate sets of interaction entities for different users does not preclude coupling of values of corresponding interaction entities created for different users. As discussed later, our framework provides a default coupling scheme and coupling-aware primitives to override this scheme. In particular, it allows users to couple the values of all corresponding interaction entities, thereby also supporting WYSIWIS [53] (What You See Is What I See) interaction. On the other hand, the former approach supports only WYSIWIS interaction since it creates a single interaction state for all users of an application. 4.2. Multi-User Architecture Research in shared window systems has identified two main architectures for a multi-user application [32]: (a) the centralized architecture, which creates a single copy of the application executed by a single operating system process and (b) the replicated architecture, which creates a local copy of the application for each user. Both architectures have serious disadvantages. The centralized architecture does not meet the requirement of flexible placement. In particular, it does not support local placement of the user-interface modules since all of them execute in a central process. As a result, it requires broadcast of potentially graphical output. Moreover, it does not meet the requirement of error independence since a local error made by a user can crash the central process, thereby terminating the whole session. It also does not meet the requirement of concurrent scheduling since a single schedulable thread is created for all users.9 Finally, it does not meet the requirement of environment independence since the central process is associated with a single environment. The replicated architecture meets the requirements of flexible placement, concurrent scheduling, and error independence since it creates a separate process for each user, which executes in its own protected address space, is 9

Unless the central operating system process contains independently-scheduled threads, as discussed in §7.2.



13

independently scheduled, and can be executed on the local workstation of the user. However, it executes semantic operations multiple times, once for each copy of the application,10 which is not always desirable since multiple invocations of a semantic operation may perform computationally expensive operations multiple times, attempt to read the same file simultaneously, attempt to write the same data to a file multiple times, access files that are not available at all workstations, and send a mail message multiple times [6, 32, 33]. Therefore, we have developed a new multi-user architecture to overcome problems of existing architectures. In multi-user Suite, each user’s interaction with a multi-user application is managed by a separate dialogue manager, which manages all interaction entities created for its user (Figure 4). The dialogue managers of different users of a multi-user application are separate Suite objects [10] and hence run as separate heavyweight system processes (scheduled independently and possibly concurrently by the underlying operating system), have separate address spaces, access rights and environments, and can be placed on different hosts. They are independently and dynamically placed, created, and connected to and disconnected from the application by their users. As in single-user Suite, they are provided by the system and perform interaction functions of the application. In addition, they also perform collaboration functions of the application. This architecture can be regarded as a combination of the centralized and replicated architectures since it supports a central semantic component (application object) and local user-interface components (dialogue managers). It does not suffer from the disadvantages of the centralized and replicated architectures and meets several other of our requirements. Clearly, it meets the requirement of dynamic binding, flexible placement, and concurrent scheduling. It also meets the requirement of error independence since errors made by users that affect the state of only their dialogue managers cannot crash the dialogue managers of other users. Furthermore, it is consistent with the requirement of user-interface independence in that it allows dialogue managers to execute with different access rights and environments. Finally, under this architecture, semantic actions are executed once in the central application component. The Suite multi-user architecture allows user-interface tasks to be performed locally but not the computation tasks. In comparison, the replicated architecture allows both user-interface and computation tasks to be performed locally, thereby not requiring a user to wait for communication delays involved in receiving output. Under our architecture, a user has to wait for communication delays involved in receiving results but not their displays, which are formatted locally by dialogue managers. Our preliminary experience shows that (a) these delays are not perceptible since the size of a result is typically small in comparison to its display and, more important, (b) results are produced infrequently since users execute long transactions before they commit their input values. For instance, (a) the size of budget is much smaller than the size of its graphical representation and (b) new values of the budget are output only when users commit their changes to the budget and not on each input event.

10

in §7.1.

Unless the application programmer explicitly writes collaboration-aware code that coordinates the replicas of an application, as discussed



14

4.3. Default Collaboration Scheme We have met the requirements of compatibility and collaboration transparency by designing a default collaboration scheme that supports multi-user applications while retaining the programming and user interfaces of the basis. We describe below its main components. Creating and Connecting with Applications We retain the interface presented by single-user Suite for instantiating an object and connecting a dialogue manager to it. Continuing with the budget example, a user can execute the command budget_example -name my_budget & to create the instance my_budget. Later, two different users, users pd and rxc can execute the commands dm -name dm_pd -load my_budget & and dm -name dm_rxc -load my_budget & respectively, to start interactive sessions with the application. Each of these commands creates a dialogue manager and connects it to the application (Figure 5). In the single-user case, the Suite calls invoked by an application were directed at a single dialogue manager, and the Suite callbacks defined by the application were invoked by a single dialogue manager. Moreover, user commands modified the state of the local dialogue manager and possibly the application. In the multi-user case, multiple dialogue managers can be associated with Suite calls and callbacks. Moreover, user commands can be coupled, that is, can affect the state of remote dialogue managers. We use several rules to decide the default semantics of the original single-user calls, callbacks, and user commands in the multi-user situation. Access Control Access Control Rule: All users of an application have equal access to corresponding interaction entities created by their dialogue managers. Moreover, a callback can be invoked by any dialogue manager whose user invokes an action that triggers its call.

Figure 5: Multi-User Interaction



15

We support this rule because the framework cannot distinguish among the different users in the absence of application-provided information. Continuing with the example, this rule implies that both rxc and pd can edit their versions of the budget and invoke a callback to update its value in the application. Demultiplexing Calls While a single rule applies to all Suite callbacks, multiple rules address the targets of Suite calls. To describe these rules, we need to classify the calls based on whether they are: responses, that is, calls executed in callbacks invoked in response to user commands, or requests, that is, calls initiated by the application. retrievals, that is, calls that return results from dialogue managers, or actions, that is, calls that ask dialogue managers to set perform operations.11 value updating calls, that is, calls that change the values of interaction variables. We first consider responses. In particular, we consider those responses that are not value update calls, which are addressed by the value update rule discussed later. Response Rule: A response (other than a value updating call) is directed at the current dialogue manager, that is, the dialogue manager that invoked the callback. This rule assumes that such a Suite call is a private response to a request by a dialogue manager that only the user of the dialogue manager is interested in. To motivate and illustrate this rule, consider the Suite calls made in the load and update callback defined in Figure 3. The Dm_Submit, Dm_SetAttr and other Suite calls invoked by the load callback are directed at the dialogue manager that invoked the callback, thereby creating object windows, interaction variables, and other interaction entities once for each dialogue manager of the application (Figure 5). Similarly, the Dm_Message call invoked by the update callback is directed only at the dialogue manager that invoked the callback. Thus, if user pd updates the budget, the debugging messages are displayed only to him (Figure 6). Consider now requests, which are Suite calls initiated by the application object. We handle action requests differently from retrieval requests, as shown by the two rules below. Action Request Rule: An action request refers to all dialogue managers connected to the application. Unlike a response, a request cannot be associated with a distinguished dialogue manager. One alternative is to choose none of the dialogue managers. However, this alternative would not perform the action even when a single dialogue manager is interacting with the application, thereby violating the requirement of compatibility. Another alternative is to non-deterministically choose any dialogue manager. However, this alternative would make the behavior of the application non-deterministic—and hence confusing. Yet another alternative is to choose the previous dialogue manager, that is, the dialogue manager that invoked the last callback. However, our experience with 11

Suite does not offer any call that both requests an action and returns a value.



16

Figure 6: User pd Commits a New Value building Suite applications shows that a request is typically unrelated to the last callback. The action request rule is based on the assumption that all requests are public and thus should be broadcast to all users. Retrieval Request Rule: A retrieval request refers to any dialogue manager, that is, a dialogue manager chosen non-deterministically by the system. As before, we cannot choose none of the dialogue managers since that would violate the requirement of compatibility. Moreover, we cannot choose multiple dialogue managers, since a collaboration-transparent retrieval request must return a single value. In comparison to previous dialogue manager, any dialogue manager can lead to better performance when users are interacting from remote sites since the system can choose the dialogue manager that is nearest to the application. However, both alternatives can cause the application to behave non-deterministically if all dialogue manager copies of the interaction entity retrieved are not identical. For instance, the behavior of an application that retrieves the value of the Titled attribute of the value group Budget would be non-deterministic unless all copies of this attribute are the same. Our coupling rules given below do allow copies of interaction entities displayed to different users to become different. Yet another alternative is to return the most recent value of the interaction entity cached in the application. This approach is more efficient but is not applicable when the interaction entity is not cached. Moreover, it can lead to non-deterministic behavior even when all dialogue manager copies of the interaction entities are identical, since these values may be different from the value cached. Finally, the following demultiplexing rule describes the multiplexing of value update calls and is related to the value coupling rule below. Value Update Rule: A Suite call to commit a new value of an active variable updates all dialogue manager copies (interaction variables) of the active variable. Coupling



17

Value Coupling Rule: Changes made by users to their local copies of active variables are also made to the corresponding copies of the variables maintained by other dialogue managers when the users commits these changes. The value update and coupling rules allow the changes made by an agent (user or application) to be shared with other agents when the agent commits them. Users commit changes by accepting them and applications commit them by invoking value update calls. These two rules are consistent with the approach to sharing adopted by traditional transaction systems, which allow users to read only committed values. To illustrate these two rules, consider what happened when user pd committed a new value of the Equipment field of budget (Figure 6). Suite assigned this value to the copy of the data structures maintained by user rxc’s dialogue manager. Moreover, as in the single-user case, it invoked the update handler UpdateBudget to inform the application about the change, which computed new values of the dependent fields and called Dm_Update to update the copies of these fields kept by the two dialogue managers. Attribute Coupling Rule: Changes made by users to attributes of value groups are not shared with other users. Window Coupling Rule: Changes made by users to the size, position, and other properties of a window are not shared with other users. These two rules allow users to independently change format, viewing, and other properties of interaction entities without affecting the displays of other users. For instance, they allow user pd to change the format of his copy of a budget field (Figure 6) and the size of his copies of the windows without affecting the displays of user rxc. We distinguish between values and attributes because we expect users to, typically, share values but not formatting and other ‘‘non-state’’ attributes. Concurrency Control Concurrency Control Rule: An active variable is locked when a user starts modifying his local copy of it and unlocked when he commits its value. When an active variable is locked by a user, other users are not allowed to change their copies of it. To motivate this rule, consider the alternatives for defining a default concurrency control rule. One alternative is to let users explicitly lock and unlock groups of active variables. However, this approach requires the use of collaboration-aware commands, which is inconsistent with the requirement of collaboration transparency. Another alternative is to lock all active variables when a user starts modifying one of them. However, this rule is too conservative in that it allows only one user to be active at any one time even if the dialogue supported by the application is multi-threaded. For instance, it does not allow users pd and rxc to concurrently edit a budget field and a comment, respectively. Yet another rule is to never lock an active variable and thus allow multiple users to simultaneously modify copies of it. However, this rule does not increase useful concurrency, since according to the value coupling rule, a commitment of one of these copies overwrites the (uncommitted) values of the other copies before they are processed by the application. These rules specify only the default collaboration scheme supported by Suite. They have been designed to meet the collaboration requirements, be consistent with each other, allow existing single-user applications to be used



18

in a reasonable way by multiple-users, and keep the collaboration awareness low in typical multi-user applications. We describe below facilities provided by Suite for allowing applications to incrementally tailor the collaboration scheme. 4.4. Collaboration-Aware Primitives One approach to supporting customization of the default collaboration scheme is to let application programmers directly modify/extend the modules provided by the system (described in Section 5) to implement it. This approach is supported in Suite since it instantiates a separate set of system modules for each application, thereby allowing the default collaboration scheme to be customized differently for different applications. However, this approach is not sufficient to meet the requirement of incremental awareness since it supports only low-level implementations of collaboration schemes and not high-level specifications of them. Therefore, our framework also offers a small but powerful set of high-level and flexible primitives for allowing an application to exercise control over how its collaboration functions are performed. These primitives allow an application to: demultiplex calls to a variety of groups of dialogue managers, thereby allowing it to display results to selected users and couple the values input by different users, identify the users of the different dialogue managers kept by the operating system, thereby allowing it to implement access and concurrency control, tailor its processing to the user, and inform a user of the identities of other users of the program, fork programs on hosts and environments of the dialogue managers of the users, set and retrieve the states of the environments of the dialogue managers, thereby allowing it to provide environment-specific processing, disable the default coupling and concurrency control schemes, thereby allowing it to completely override the default processing of these functions, A program that uses these primitives is aware of the fact that multiple users are interacting with it. Therefore, we refer to these primitives as collaboration-aware primitives. These primitives have been designed to meet our goal of incremental awareness. They allow programs to be completely aware of collaboration, that is, completely implement their collaboration functions. In addition, they provide three ways for programs to become increasingly aware of collaboration. First, they allow programs to independently override the default implementations of the various collaboration functions, thus allowing them to implement these function incrementally, which is illustrated by the various versions of the example application described below. The version of Section 4.4.1 overrides the default demultiplexing of output and adds collaboration-awareness to the user-interface, the version of Section 4.4.3 implements access control, the version of Section 4.4.4 overrides the default program invocation scheme provided by the operating system, and finally, the version of Section 4.4.6 overrides the default coupling scheme.



19

Second, they allow programs to incrementally override the default implementation of a specific collaboration function instead of completely replacing it with a new implementation. For instance, the version of the example program given in Section 4.4.2 does not disable all of the default output demultiplexing— it demultiplexes only three of the output calls. Similarly, the version of Section 4.4.5 changes the default coupling scheme for only one of the displayed data structures. Finally, they allow programs to become incrementally more aware of the details of implementing a specific collaboration function. In particular, they allow a program to be aware of only the name of a group of users, or the specific users of a group, or the identities of the specific sessions (dialogue managers) of the users of a group. By supporting incremental awareness, our framework allows programs to incrementally trade automation for flexibility and tailor only those aspects of the default collaboration scheme that are necessary to offer the desired collaboration scheme. We motivate, describe, and illustrate these primitives below. 4.4.1. Generic-Groups We identified in Section 4.3 three useful groups of dialogue managers to which a Suite operation may be directed: current, any, and all. Two other such groups are the others group and the parameterized session group. The former refers to all users other than the current user and may be the target of a Suite call that, for instance, displays a message to all other users when a new user starts a session with the application. The latter is parameterized by an integer, n, and refers to the nth session in a list of sessions sorted by when they were started. This group may be used, for instance, by applications such as DCS [38] and a multi-user debugger we have built that check with the user of the first session with the application if a particular user should be allowed to enter the conference. Suite allows an operation to be explicitly invoked on these groups of dialogue managers. For instance, in addition to the default Dm_Message

call,

it

provides

the

calls,

Dm_Message_Current,

Dm_Message_Others,

Dm_Message_Any, Dm_Message_All, and Dm_Message_SessionNo. Suite operations invoked on the dialogue manager groups current or others must be executed in callbacks. We have modified the update callback of Figure 3 to illustrate the use of these calls: void UpdateBudget(name, val) char *name; Budget *val; { #ifdef DEBUG Dm_Message_All ("UpdateBudget Starts"); #endif ... ExampleBudget = *val; Dm_Update ("ExampleBudget", "Budget", val); Dm_Message_Others ( "Budget Updated"); #ifdef DEBUG Dm_Message_All ("UpdateBudget Terminates"); #endif }

The two

Dm_Message_All calls allow all users of an application to debug the application.

The

Dm_Message_Others call alerts all users other than the one who made the change that the budget has been modified, thereby creating a collaboration-aware user interface for the application. Thus, if user pd commits a new



20

value of the budget, user rxc is informed of the change (Figure 7). These groups are generic groups in that they are defined independently of specific applications and users. Moreover, they are dynamic groups in that they are formed at execution time and can change with every user action. We discuss below primitives that allow applications to target Suite calls at application-defined groups based possibly on static properties of the applications and its dialogue managers such as their owner. 4.4.2. User-Defined Groups Suite provides procedural and interactive primitives for creating user-defined groups. An application may invoke the procedure Gm_MakeGroup to make a new group of users, Gm_AddUser to add a user/group to an existing group, Gm_DeleteUser to delete a user/group from an existing group, and Gm_RemoveGroup to remove an existing group. These procedures are processed by a special global object called the group manager. The group manager also allows users to interactively create/remove groups and add/delete group members. Suite allows an operation to be invoked on the dialogue managers of all users in a user-defined group. For instance, it provides the Dm_Message_Group call, which takes as the first argument a name of a user-defined group, and prints the message on the dialogue managers of all users in the group. A facility for creating user-defined groups is also supported by UNIX-like operating systems. Unlike Suite user-defined groups, these groups are heavyweight groups in that they are associated with access rights and can be modified only by users with special privileges. Suite groups are intended to be lightweight groups that can be created and manipulated dynamically by arbitrary applications and users. Since access groups defined by the operating system can also be collaboration groups, Suite allows group-based operations and commands to refer to them using a special prefix. Figure 8 illustrates interactive definition of a group consisting of an existing UNIX access group and the user lane. The user displays the current set of Suite groups, edits a template to define the new group, and executes the accept command to commit the group. At this point, all applications and users can refer to the group. For instance, an application can execute the call

Figure 7: Generic Groups



21

Figure 8: User-Defined Groups Dm_Message_Group ("suite", "Hello Suite Users") to display a message to users in the group. Unlike programs that use generic groups, programs that use these groups are tied to a particular set of groups, and cannot be ported directly to a Suite system that does not support these groups. They can, however, be ported to Suite systems that define the groups differently. For instance, a multi-user program that refers to the suite group can be ported to systems that include different sets of users in this group. 4.4.3. Specific Users and Sessions A multi-user application may need to be aware of the identities of specific users, for various reasons. First, it may want to implement access control. For instance, the example application may not wish to allow selected users to add comments. Moreover, it may want to tailor its processing of input and displaying of output to the user. For instance, the example application may wish to use a user’s favourite editor when displaying the application description to him. Furthermore, it may want to create collaboration-aware user-interfaces that inform a user about the identities of other users. Therefore, Suite supports user-aware primitives. It allows each of the Suite operations to be invoked on all dialogue managers invoked by a particular user. For instance, it provides the Dm_Message_UID call, which asks all dialogue managers of a particular user to display the message. It also allows the applications to determine which users are interacting with it. It supports the Dm_GetUID operation, which can be used to get the identity of the user of a dialogue manager. Like other operations, it can be invoked on various groups of dialogue managers supported by Suite. For instance, an application can invoke Dm_GetUID_Others in a callback to get the identities of users of all dialogue managers other than the current dialogue manager. We illustrate user awareness by adding two callbacks to the example application: CommentInsertionValidate, which is invoked by Suite to check if the addition of a new comment should be allowed, and CommentInsertionUpdate, which is invoked by Suite to inform the application of the new comment. These callbacks



22

are outlined below: char * CommentInsertionValidate (seq_name, child_name, index) char *seq_name, *child_name; unsigned index; { if (CheckAccess (Dm_GetUID_Current())) return ((char *) 0); else return ("Comment Insertion not allowed"); } void CommentInsertionUpdate (seq_name, child_name, index) char *seq_name, *child_name; unsigned index; { Dm_SetAttr_All(child_name,AttrPreString,NameFromId(Dm_GetUID_Current())); Dm_SetAttr_Others (child_name, AttrReadOnly, 1); }

CommentInsertionValidate checks the access rights of the user and CommentInsertionUpdate labels the comment with the name of the user (Figure 9) and makes it read-only for all users other than the current user. A multi-user application may also need to be aware of properties of specific user sessions represented by the dialogue managers. For instance, the example application may wish to use an editor specified dynamically by the user during the interaction session.

Therefore, Suite also provides session-aware primitives.

It provides the

Dm_GetSessionID family of calls, which returns identifiers of various groups of dialogue managers and allows an operation to be invoked on a dialogue manager named by one of these identifiers. For instance, it provides the Dm_Message_SessionID call, which is targeted at the dialogue manager specified by its argument. 4.4.4. Program Execution Like single-user applications, multi-user applications need to sometimes execute programs dynamically. For instance, a multi-user command interpreter may need to execute a program in response to a user command. In the single-user case, it is reasonable to execute a single instance of the program in the environment of the application, since the application is bound to a single user. As a result, calls such as system provided by the operating system are usually sufficient to support program execution. However, in the multi-user case, program execution must be more flexible, as discussed below. Continuing with the example of the multi-user command interpreter, assume that the program to be invoked is a single-user program such as the UNIX gnumacs program. Executing the program once would be inappropriate if

Figure 9: User Awareness



23

multiple users of the command interpreter wish to start the editor. Moreover, executing it in the environment of the invoking application would usually be inappropriate since, in general, different users of a multi-user application have different environments which are distinct from the environment of the application. On the other hand, if the program to be invoked is itself a multi-user program such as the Suite budget_example program, then executing it once in the environment of the invoker is usually appropriate, since a single instance can interact with multiple users and is not associated with any one user’s environment. A general approach to supporting flexible invocation of single-user programs from a multi-user application is to make the latter aware of the environments of its users (Section 4.4.5), thereby allowing it to invoke operating system calls such as system multiple times in the appropriate environments. However, this approach makes the overhead of invoking programs high since the invoker must construct a suitable environment for each user instead of letting it inherit it from an existing program. Often a multi-user application simply wishes to invoke a program in the environments of its users. Therefore, Suite provides the Dm_System family of calls, which invoke programs in the environment of the different groups of dialogue managers of the application. As a result, it is possible to change the system call of Figure 3 with one of these calls to allow multiple users to view the output of the single-user gnumacs program, as shown below: void DescribeApp (name, val) char *name; String *val; { Dm_System_All ("gnumacs README &"); }

The Dm_System_All call invokes the gnumacs program once for each user in the environment of the user (Figure 10). The Dm_System calls are useful for invoking not only non-Suite single-user programs such as gnumacs but also the Suite single-user programs—the dialogue managers. For instance, the example application can create a new instance of budget_example and connect all of its users to the new application by simply executing: system ("budget_example -name his_budget &"); Dm_System_All ("dm -load his_budget &");

Figure 10: Flexible Program Forking



24

Giving an application the capability of asking a dialogue manager to execute programs raises an access control problem— it allows the application to execute malicious programs with the rights of the users of the program. We plan to address this problem by allowing the users to restrict the programs their dialogue managers execute. 4.4.5. User Environments The example above is aware that it is being used by users with environments that are different from its environment. However, it is not aware of specific properties of the environment — it simply executes the command in the current user’s environment. In general, a multi-user application may need to directly refer to specific properties of the environments of its users, for at least three reasons. First, it may need to execute a command that uses properties of a user’s environment even when the user is not connected to the application. For instance, the example application may wish to display a message on the displays of both past and current users of the application when a new user joins the conversation or when the value of the budget is committed. Second, access control may not allow it to execute a command in the user’s environment. For instance, a user of the application may not have rights to execute the gnumacs program. Finally, the application may need to compose properties of multiple environments. For instance, a user of the example application may not have gnumacs in his search path— therefore the application may wish to use its search path but the user’s display when invoking gnumacs. Therefore, Suite provides two additional operations to support environment-aware applications. It provides the Dm_GetEnv and Dm_SetEnv operations to set and get properties of the various groups of users. The modified DescribeApp procedure below illustrates the use of one of these operations: void DescribeApp(name, val) char *name; String *val; { char *display; display = Dm_GetEnv_Current ("DISPLAY"); sprintf (cmd, "gnumacs -display %s README &", display); system (cmd); }

Several of the operations defined above such as Dm_System, Dm_GetEnv, and Dm_GetUID are direct extensions of corresponding operating system operations. In a multi-user system implemented on top of a collaboration-unaware operating system, operations that access information about users cannot be directly processed by the operating system since it does not know who the user of an application is. 4.4.6. Control Operations Suite also provides operations to disable and enable the default coupling and locking schemes for a data structure, which, together with the primitives described above, can be used by a coupling-aware/concurrency-aware program to override the default coupling/concurrency-control schemes. To illustrate, consider again the example application. Suppose it wishes to override the default coupling scheme by allowing only users in the suite group to share changes to the budget and informing users incrementally about changes to the budget made by other users. It can disable the default coupling scheme for this data structure, use the flexible feedback model provided by single-user Suite [9] to receive incremental changes to the data structure, and invoke Dm_Update_Group in the update callback for the data structure to manually couple the interaction variables for it, as shown below:



25

void UpdateBudget(name, val) char *name; Budget *val; { Dm_Update_Group (name, "Budget", "suite", val); }

Now suppose that the application wishes to implement a concurrency control scheme that lets a user explicitly lock and unlock a data structure. It can override the default locking scheme for all data structures, define the lock and unlock commands using the facility provided by single-user Suite for defining application-specific commands, and lock (unlock) a user’s interaction variable by setting its ReadOnly attribute to True ( False ). 5. Implementation The implementation of multi-user Suite is an extension of the implementation of single-user Suite. The implementation of single-user Suite consisted of a dialogue compiler, which was used to compile declarative dialogue specifications [9] and build a symbol table from the type declarations; single-user dialogue managers, which managed the various interaction entities supported by single-user Suite; and library routines such as Dm_SetAttr used by applications to communicate with dialogue managers, which simply forwarded the requests to the dialogue manager. The dialogue compiler has been directly reused in multi-user Suite since we have not added new types or dialogue specifications. The library routines and the dialogue manager have been extended in various ways. Finally, a group manager has been added to support user-defined groups. A dialogue manager of a multi-user application performs several additional functions. First, it exchanges coupling information with other dialogue managers connected to the object. Second, it locks and unlocks interaction variables and exchanges locking and unlocking information with its peers. Finally, it implements several new operations described above such as the control operations and the

Dm_GetSessionId,

Dm_GetUID, and

Dm_System operations. The implementation of several of these operations such as Dm_GetUID and Dm_System simply invokes corresponding operating system operations. A dialogue manager is unaware of the identities of its peers and does not send messages directly to them. Instead, it sends them to the application object, which distributes them to all of its peers. Routing messages among dialogue managers through the application object makes it easy to ensure that coupling messages are received in the same order by each dialogue manager and locking and unlocking is done atomically. The library routines linked to a multi-user object perform two additional functions. First, they implement multiplexing of the Suite operations among the various dialogue managers. Second, they route and distribute coupling, locking, and unlocking messages among dialogue managers. They maintain a list of the session identifiers of the dialogue managers connected to the object, which is used for performing both functions. They also maintain information about the order in which the dialogue managers were connected to the object and the identifiers of users of these dialogue managers to support session and user groups, respectively. The group manager creates user-defined groups and maps the name of such groups to the names of the users belonging to the groups. It is itself a Suite object [10] and provides a procedural and multi-user interactive interface. Each client of a group manager registers itself with the group manager and maintains a cache of group definitions. When a group definition changes, the group manager informs its clients about the new definition, which can then



26

update their caches. 6. Examples The budget example is only one of the multi-user applications we have implemented using Suite. In this section, we describe other examples to show how different classes of multi-user applications are implemented using our framework. We show examples of Suite programs that (a) allow users to concurrently edit shared data structures, (b) communicate messages among users, (c) allow users to share results of computations, and (d) extend existing singleuser programs that have not been developed using single-user Suite. Figure 11 shows the user-interface of a simple text editor allowing users to concurrently edit a text string. Figure 12 shows its implementation in Suite. As shown in Figure 12, the program is responsible only for creating a string active variable. Suite handles collaboration tasks for the program such as connecting users to the application, creating local buffers (interaction variables) of the text string for them, coupling these buffers, and implementing concurrency control. A multi-user text editor is a trivial representative of the class of multi-user data-structure editors. Figure 13 shows a more complex example of this class. These editors differ only in the types of the active variables they display, as illustrated by Figures 12 and 14. Figure 15 shows the user-interface of a two-person talk program, which allows two users to talk with each other using different windows and prevents a user from typing in the wrong window. Figure 16 shows the implementation of the program. Unlike the previous programs, this program is aware that it is interacting with multiple users. The Load callback keeps a count of the number of times it was called and allows only two users to connect to the

Figure 11: User-Interface of Multi-User Text Editor /*dmc Editable String */ String text = ""; Load () { Dm_Submit (&text, "Text", "String"); Dm_Engage ("Text"); }

Figure 12: Implementation of Multi-User Text Editor



27

program. It creates separate text buffers for each user and makes a user’s text buffer read-only for the other user. Figure 17 shows the user-interface of a simple mail program and Figure 18 shows its implementation. The program creates two interaction variables for each user, one for the outgoing message and the other for the list of received messages. Unlike the programs above, this program completely implements the coupling among its interaction variables. It disables the default coupling among the incoming and outgoing messages of the different users and couples outgoing messages of a user with lists of incoming messages of other users. It defines an update procedure for the outgoing message that explicitly inserts the message into the list of incoming messages of the destination user.

Figure 13: User-Interface of Multi-User Outline Editor /*dmc Editable Outline */ typedef struct { unsigned num; struct section *sec_arr; } SubSection; typedef struct section { String Name; String Contents; SubSection Subsections; } Section; typedef struct { unsigned num; Section *sec_arr; } Outline; Outline outline; Load () { Dm_Submit (&outline, "Outline", "Outline"); Dm_Engage ("Outline"); }

Figure 14: Implementation of Multi-User Outline Editor

Figure 15: User-Interface of 2-Person Talk Program



28

/*dmc Editable String */ String UserA = "", UserB = ""; int talkers = 0; Load () { if (talkers < 2) { talkers++; Dm_Submit (&UserA, "UserA", "String"); Dm_Submit (&UserB, "UserB", "String"); if (talkers == 1) Dm_SetAttr ("View: UserB", AttrReadOnly, 1); else Dm_SetAttr ("View: UserA", AttrReadOnly, 1); Dm_Engage_Specific ("UserA", "UserA", "Text"); Dm_Engage_Specific ("UserB", "UserB", "Text"); } }

Figure 16: Implementation of 2-Person Talk Program The programs above support sharing only of data entered by users. Figure 19 shows the user-interface of a simple spreadsheet which allows users to also share results computed by the program. It allows users to enter a list of named numbers and computes the sum of these values for them. Figure 20 shows the code of the program. Like the mail program, it defines an update procedure to process the input of users. The procedure computes and displays results instead of routing information among users. Finally, Figure 21 shows an example of a multi-user command interpreter and Figure 22 shows its implementation. The program displays a list of user commands and their outputs and responds to the entry of a new command by updating the corresponding output and appending a new entry to the list. It uses an existing command interpreter to compute the output of a command by using facilities provided by the operating system to create pipes of programs. Moreover, it simulates the user interface of the existing command interpreter by setting an attribute that causes a dialogue manager to automatically commit a command when the user hits the RETURN key. The command interpreter is an example of the class of Suite multi-user programs that extend single-user programs that have not been

Figure 17: User-Interface of Mail Program



29

/*dmc Editable Msgs */ typedef struct { String From, To, Text; } Msg; typedef struct { unsigned num; Msg *msg_arr; } Msgs; Msg Outgoing; Msgs Incoming; struct passwd *pwd; char *VerifyUser (name, val) char *name; String *val; { if ( (pwd = getpwnam(*val)) != Null(struct passwd)) return Null (char); else return "Unknown User"; } void Send (name, val) char *name; Msg *val; { Dm_SequenceElementAppend_UID (pwd->pw_uid, "Incoming", "Msg", val); } Load () { Outgoing.From = Dm_GetUser (); Dm_Submit (&Outgoing, "Outgoing", "Msg"); Dm_Submit (&Incoming, "Incoming", "Msgs"); Dm_SetAttr ("View: Outgoing", AttrValueCoupled, 0); Dm_SetAttr ("View: Outgoing", AttrUpdateProc, Send); Dm_SetAttr ("View: Outgoing.To", AttrVerifyProc, VerifyUser); Dm_Engage ("Outgoing"); Dm_Engage ("Incoming"); }

Figure 18: Implementation of Mail Program developed using Suite. As illustrated above, the user-interface of such a single-user program must be recreated, if possible, using Suite to allow the program to use the multi-user support provided by it. In general, this task is not difficult since, as illustrated above, Suite provides high-level primitives for generating user interfaces. However, as mentioned before, Suite cannot be used to create arbitrary user-interfaces since it does not currently support generation of highly graphical user-interfaces such as those provided by VLSI editors. We have shown here trivial examples of the different classes of multi-user applications to emphasize the structure of Suite programs that implement them. Based on the discussion in Section 4.4, it is easy to see how more complex representatives of these classes can be implemented. For instance, it is easy to see how the talk program can support an arbitrary number of users, the mail program can support mail headers and browsing of them, and the spreadsheet can support arbitrary computations. This section shows that Suite can be used to easily implement a variety of multi-user applications, thereby illustrating the automation and flexibility provided by our approach. The few lines of code shown above replace thousands of lines of code that would be required to implement these applications manually. 7. Related Work Our work on multi-user Suite is closely related to a variety of other works addressing multi-user interaction including database systems, shared-window systems, group toolkits, and shared-object systems. The differences between our framework and these systems arise mainly because of differing design goals. In particular, none of these systems was designed to meet the set of requirements given in Section 2. We briefly describe these works and discuss



Figure 19: User-Interface of Multi-User Spreadsheet /*dmc Editable ElementSeq */ typedef struct { String Name; int Number; } Element; typedef struct { unsigned num; Element *elm_arr; } ElementSeq; ElementSeq List; int Total; Compute (name, list) char *name; ElementSeq *list; { int i; for (i = 0, Total = 0; i < list->num ; i++ ) Total += list->elm_arr[i].Number; Dm_Update ("Total", "int", &Total); } Load () { Dm_Submit (&List, "List", "ElementSeq"); Dm_Submit (&Total, "Total", "int"); Dm_SetAttr ("Type: ElementSeq", AttrUpdateProc, Compute); Dm_SetAttr ("Type: Element.Number",AttrWidget,AttrHorizontalScrollbar); Dm_SetAttr ("Type: Element.Number", AttrMaxValue, 10000); Dm_Engage_Specific ("List", "Object", "Graphical"); Dm_Engage_Specific ("Total", "Object", "Graphical"); }

Figure 20: Implementation of Multi-User Spreadsheet

30



31

Figure 21: User-Interface of a Multi-User Command Interpreter /*dmc Editable CmdSeq */ typedef struct { String Cmd, Result; } CmdRec; typedef struct { unsigned num; CmdRec *cmd_arr; } CmdSeq; CmdRec Init = {"", ""}; CmdSeq CmdList = {1, &Init }; void Execute (cmd_name, val) char *cmd_name; String *val; { int index; char output_name[1024]; char *result; sscanf (cmd_name, "(((CmdList)[%d]).Cmd)", &index); sprintf (output_name, "(((CmdList)[%d]).Result)", index); /* execute command using popen() and capture output */ result = ExecuteCommand (*val); Dm_Update (output_name, "String", &result); Dm_SequenceElementAppend ("CmdList", "CmdRec", &Init); } Load () { Dm_Submit (&CmdList, "CmdList", "CmdSeq"); Dm_SetAttr ("Type: String", AttrAcceptOnReturn, 1); Dm_SetAttr ("Type: String", AttrUpdateProc, Execute); Dm_SetAttr ("View: CmdList", AttrTitled, 0); Dm_SetAttr ("Type: CmdRec.Cmd", AttrTitled, 1); Dm_SetAttr ("Type: CmdRec.Cmd", AttrTitleString, "> "); Dm_SetAttr("Type: CmdSeq",AttrSequenceComponentAlignment,AttrVertical); Dm_SetAttr("Type: CmdRec",AttrRecordComponentAlignment,AttrVertical); Dm_Engage ("CmdList"); }

Figure 22: Implementation of a Multi-User Command Interpreter their relationship with our framework. 7.1. Database Systems The Suite multi-user framework is related to recent work in database systems. A Suite object is like a traditional database in that it stores data structures that can be read and modified by multiple users, and a Suite shared active variable is similar to a shared database entity. Moreover, invoking the commit command in Suite is similar to completing a transaction in database systems and locking Suite variables is similar to locking the read and write sets of a database transaction. Finally, invoking update callbacks in Suite application objects is similar to executing triggers in active databases [37].



32

The differences between database systems and the Suite multi-user framework stem from the fact the former are designed to support non-interactive transactions based on query languages while the latter has been designed to support interactive transactions based on the editing model. As a result, database systems do not provide equivalents of the Suite interaction variables, multi-user architecture, user interface, or any component of the programming interface except the update callbacks. 7.2. Shared-Screen and -Window Systems Shared-screen systems such as NLS [20] and shared-window systems such as VConf [32], Rapport [21], Shared X [25], and MMConf [6] are extensions of single-user screen/window systems. These systems allow a client program to display copies of a screen/window to different users of the program and have been implemented using both the centralized and replicated architectures. Like Suite, they dynamically create/destroy copies of interaction entities (shared screens/windows) when a user makes/breaks a connection with a program, offer the client a programming interface for collecting input from and demultiplexing output to multiple users, and implement concurrency control. Moreover, like Suite, they support collaboration-transparent programs including existing single-user programs developed using their single-user counterparts. Furthermore, like Suite, MMConf supports collaboration-aware primitives, including primitives for broadcasting messages to all users. The main difference between these systems and Suite is that they manage low-level interaction entities such as windows and screens. Shared-screen and -window systems greatly increase the power of interactive systems. Since they extend lowlevel user interface tools, they can be used to perform the collaboration tasks of not only direct clients of these tools but also clients of higher-level tools that use these low-level tools. For instance, a shared X window system can be used to perform the collaboration tasks of not only direct clients of the X window system but also the clients of the large number of toolkits and user interface management systems developed on top of the window system. However, these systems also suffer from an important limitation. Since they manage low-level interaction entities, they cannot create multiple copies of the interaction entities defined by higher-level user-interface software such as toolkits and UIMSs. As a result, they force users to share these entities, thereby supporting near-WYSIWIS interaction. For instance, a shared X window system forces users to share scrollbars since the notion of a scrollbar is defined by higher-level toolkits. A high-level system such as Suite does not suffer from these limitations since it creates multiple versions of interaction entities defined both by it and lower-level layers such as the toolkit and window system. These systems differ from Suite in several other related respects. They support either the centralized architecture or the replicated architecture, while Suite supports a hybrid architecture. The default collaboration scheme provided by them is also different. It does not distinguish between retrievals and actions, responses and requests, and value updates and other calls. Moreover, the collaboration-aware primitives supported by MMConf, the only collaboration-aware shared-window system known to us, and Suite are different. MMConf supports these primitives mainly to allow applications to explicitly overcome the problems of replicated architectures described in Section 4.1. Specifically, the MMConf primitives have been designed to allow the replicas of an application to synchronize each other, share non-global data, limit side-effects, and execute in parallel. They do not include equivalents of any of the



33

collaboration-aware primitives provided by Suite except the primitives that allow broadcast of a call to all users. In Section 8.2 we discuss how some of the concepts used in the design of multi-user Suite can be used to make multiuser frameworks based on single-user window systems more flexible. 7.3. GroupKit GroupKit [46] is a recent multi-user framework which uses a single-user toolkit as a basis. It has been designed to support the replicated architecture, access control, floor control, dynamic binding, and overlaying of cursors and annotations on displays created by single-user applications. It offers several predefined classes to transform a single-user application developed using the basis to a multi-user application. These classes can be used directly by a programmer or subclassed to provide application-specific functionality. The set of predefined GroupKit classes correspond to the Suite default collaboration scheme and extending these classes corresponds to using the Suite collaboration-aware primitives. The main differences between the two frameworks, which were developed independently, are: First, unlike Suite, GroupKit has no knowledge of the application data model. As a result, it offers no support for sharing data without sharing their presentations or fine-grained concurrency control. Second, unlike Suite, it supports the replicated architecture. Third, it does not offer analogues of any of the Suite collaboration primitives except the primitives for broadcasting values to all users. On the other hand, it offers overlays, which are not currently supported by Suite. 7.4. Shared-Object Systems Multi-user programs are also supported by Colab [53] and Rendezvous [41, 42], which provide shared-object systems for building these programs. Both systems allow the computation and interaction entities of an interactive program to be implemented as a set of communicating fine-grained objects and provide mechanisms for keeping objects created for different users consistent. Colab Colab supports the abstraction of an association of object representations called associates and a facility for sharing state among the associates in an association. An association can define special methods called broadcast methods that are invoked on all members of the association. This facility can be used to transform a single-user program to a multi-user program by replacing each object in the single-user program by an association, marking some of the methods of the association as broadcast methods, and creating an associate in the association for each user of the program. Care has to be taken to ensure that a broadcast method invoked in an association does not invoke other broadcast methods. A separate process is created for each user of a multi-user program, which executes on the workstation of the user and stores the associates created for that user. Colab is similar to Suite in several respects. Both Colab and Suite support collaboration-aware multi-user programs. Moreover, a Colab association corresponds to a Suite shared active variable and an associate in the association corresponds to a copy of the active variable created by a dialogue manager. Finally, invoking a Colab broadcast method is analogous to invoking a Suite call on all dialogue managers and invoking a Colab non-broadcast method is analogous to invoking a Suite call on the current dialogue manager.



34

Colab also differs from Suite in several important ways. First, it does not offer equivalents of the Suite default collaboration rules and thus does not support collaboration-transparent programs. Second, it does not support equivalents of the other, any, session, user, session-id, and user-defined groups. As a result, it is not possible to invoke a method in several useful subsets of an association. Finally, unlike Suite, Colab supports a replicated architecture. Rendezvous Rendezvous supports an alternative multi-user object-oriented framework, which is closer to Suite and was developed independently about the same time as Suite. Unlike Colab, Rendezvous distinguishes between abstract objects and view objects. The former define underlying data while the latter define how these data are viewed and manipulated by users. For each multi-user program, Rendezvous creates a single abstract process, which stores the abstract objects defined by the program. Moreover, for each user of the multi-user program, it creates a view process, which stores all of the view objects created for that user. The abstract process and view processes created for a multiuser program are lightweight processes that execute in a single address space. There are several similarities between Rendezvous and the Suite multi-user framework. Rendezvous abstract and view processes correspond to Suite application objects and their dialogue managers, respectively. Moreover, Rendezvous abstract and view objects correspond to Suite shared active-variables and the corresponding interaction variables. Finally, both Rendezvous and Suite allow coupling of semantic values without coupling of their presentations. There are also several differences between Rendezvous and Suite. A Rendezvous view process created for a user executes at a central site in the same address space as the corresponding abstract process, whereas a Suite dialogue manager created for a user executes in its own address space residing possibly on the workstation of the user. As a result, Rendezvous does not support error, access, and environment independence and flexible placement. Moreover, a Suite interaction variable is created automatically by the Suite Dm_Submit call while a Rendezvous view must be implemented by the programmer. Finally, Rendezvous does not support equivalents any of the Suite collaboration-aware primitives except the primitives to broadcast values. 8. Applying our Approach to Other Systems While our approach was designed specifically for extending a basis that has all of the properties described at the end of Section 3, several aspects of it can also be used to extend single-user systems that do not have one or more of these properties. Here we briefly consider interactive programming languages, window systems, and toolkits. 8.1. Interactive Programming Languages Most programming languages offer synchronous I/O calls such as the Pascal Read and Write calls for programming user interfaces. The concepts of directing calls at various groups, creating a runtime agent for each user, and querying and setting a user’s environment and executing programs in it can be applied to these languages. Thus, it would be useful to provide, for instance, calls such as WriteAll and WriteOthers in Pascal. Not all groupings proposed in Section 4 are applicable or appropriate in this context. The current (and hence other) groups are no longer valid, since conventional languages do not support the notion of an I/O callback. The any



35

group is not appropriate since an input call targeted at this group can block for a long time if the system nondeterministically chooses, for instance, a user who is away from his terminal. It is more appropriate to define current as the last user who input a value, thereby allowing, for instance, a program to read a data item from the same user it read the previous item from. Moreover, in the case of an input call, it is useful to queue the values input by different users and define any as the first one of the values in the queue, thereby ensuring there is no starvation. A default concurrency control rule can ensure that at any one instant there is only one user with pending input. In particular, it can ensure that the input stream is locked when a user submits input and unlocked when he commits the input buffer by hitting the return key. The default target groups of the input and output routines can now be defined as any and all. More aspects of our approach can be applied to unconventional languages such as EZ [24] that support editing-based synchronous I/O constructs. EZ offers the edit construct, which displays an arbitrary EZ data structure to a user, provides the user with an editing interface to enter a value for the data structure, and returns when the user exits the editor. This construct is a cross between I/O primitives offered by conventional languages and Suite. Like a conventional read primitive, it is synchronous, and like Suite’s Dm_Submit primitive, it submits a variable for editing. Since EZ supports synchronous constructs, the default user-groups described for conventional synchronous constructs are also appropriate for it. However, unlike conventional languages, it does not have to support a coarse-grained concurrency control mechanism. Since it supports editing of data structures, it can support a Suite-like fine-grained concurrency control scheme that ensures that different users can edit different parts of a data structure submitted for editing by the application. 8.2. Window Systems and Toolkits Like Suite, window systems and toolkits support asynchronous callbacks and calls. As a result, most of the Suite default collaboration rules and all of the groupings can be directly applied to them, which would allow, for instance, a client to update only the current user’s window in response to a refresh request. However, it may not be as useful to apply all aspects of our approach to these systems since they address user interaction at a lower level. As mentioned before, while these systems can create separate sets of the interaction entities defined by them or lower layers, they cannot create separate sets of interaction entities defined by higher layers. Thus, a shared window system cannot create separate sets of scrollbar resources and a toolkit cannot create separate sets of Suite-like value groups. Moreover, the window system and toolkit concept of a state of an interaction entity may be different from the application concept of a state. Consider the comments window of the budget application. A window system would consider the displayed state to be the bitmap displayed in the window and a toolkit implementing the window as a text widget would consider the state to be the value of the text buffer displayed in the buffer, while the application would consider it to be the value of the comments data structure. As a result, it is less useful in these lower-level systems to distinguish, for instance, between calls that update state and those that update formatting properties of the state. Furthermore, the coupling and concurrency-control rules supported by these systems cannot be based on interaction entities and operations defined by higher-level user-interface software. For instance, unlike multi-user Suite, a shared window system based on X cannot lock a scrollbar when the user starts moving it since the concept of a scrollbar and moving



36

it is defined by higher-level software. 9. Conclusions and Future Work Multi-user programs are necessary for automating the large amount of time people spend in group activities [8]. Multi-user Suite has been designed to support the easy construction of such programs. It has been used so far by 15 programmers at Purdue and the University of Minnesota to create several experimental multi-user applications including a multi-user ‘‘line-printer tool’’, which allows users to view and edit line printer queues; a multi-user talk program; a multi-user command interpreter; a multi-user ‘‘visitor tool’’, which allows members of an organization to schedule meetings with visitors and view and manipulate information about them [17]; a multi-user ‘‘expense service’’, which allows a group of users to display and manipulate their common expenditures; a multi-user ‘‘employee service’’, which manages records of the employees in an organization; a multi-user ‘‘SERC tool’’, which allows multiple users to display and modify project, budget, and other information of the Purdue Software Engineering Research Center (SERC); a multi-user ‘‘library service’’, which allows users to borrow and return books; a multi-user ‘‘voting tool’’, which allows users to vote on some issue; a multi-user spreadsheet; a multi-user query-based interface to a database management system [39]; a multi-user debugger; a multi-user ‘‘RCS tool’’, which allows users to view and edit the state of a version control system, a multi-user ‘‘C Tool’’, which allows users to browse and test C programs; and a multi-user code inspector [18], which allows users to annotate documents.12 Our experience with building some initial versions of the earlier multi-user applications helped us identify issues in the design of multi-user Suite and choose approaches for addressing them. We motivated our design using a specific example of a multi-user tool. It is also possible to make some general statements about the design by describing the kind of multi-user applications it can support. Ellis et al [19] describe two alternate taxonomies for classifying multi-user applications—the time space taxonomy and the application-level taxonomy. The former classifies applications based on two considerations: (1) whether they support collaboration that is face-to-face or distributed over many locations, and (2) whether they support synchronous (realtime) collaboration or asynchronous collaboration. The Suite collaboration-aware primitives allow Suite to support applications with a variety of synchronization needs including pure-synchronous and pure-asynchronous applications. The ability of Suite to support distributed interaction depends on how many of the interaction tasks can be performed locally, which in turn depends on many factors including the collaboration awareness of the application. An application that is more collaboration aware may need to process more user events, and would thus be less suitable for distributed interaction. Our abstractions and programming interface have been designed to keep the collaboration awareness low in multi-user applications. 12 Most of these tools have been implemented over the last one year and so far used only in demonstrations. The code inspector has been used in initial pilot studies by researchers at the University of Minnesota. Their initial experience with it suggests some advantages of collaborative code inspection over traditional manual inspection [18]. We intend to integrate the software engineering tools mentioned above into a FLexible Environment for Collaborative Software Engineering (FLECSE), which we intend to use for promoting the distributed, collaborative development of Suite tools between researchers at Purdue and the University of Minnesota [15]. This work is part of an NSF effort towards developing a ‘‘collaboratory’’ [47].



37

The application-level taxonomy characterizes multi-user applications by their functionality. It divides these applications into various groups including message systems, multi-user editors, computer conferencing systems, and coordination systems. Multi-user Suite can be used to easily implement the collaborative aspects of these applications. Indeed, several of the experimental applications we have built fall into one or more of these classes. To illustrate, consider the final version of the budget application described in this paper. Like message systems, it allows users to exchange messages; like multi-user editors, it allows users to edit shared data structures; and like coordination systems, it automatically triggers users’ actions by informing other interested users about them. Several of the other applications we built also combine features of a variety of multi-user systems. The collaborative aspects of these diverse applications were relatively easy to implement—Suite implemented most of these aspects and the applications typically contained very little code to customize the collaboration. Each of these tools was built on the average in about half a semester by a student, who used most of that time to learn Suite, design the tool, and integrate it with some existing single-user tool implementing part of the semantic component of the tool. The automation supported by Suite is illustrated by the example applications described in this paper, which provide the functionality of a variety of multi-user applications with a few lines of code. The framework described here is only an initial step towards a high-level system for supporting a wide range of multi-user applications. It is incomplete in many ways: First, it does not address the semantics of multi-user undo/redo. We are currently investigating appropriate rules for defining the default semantics of multi-user undo/redo and undo/redo aware primitives for overriding these semantics [5]. Second, it does not support user-customization of the collaboration scheme. For instance, it does not allow a user to disable the default concurrency control mechanism. Moreover, it requires that programmers write non-trivial code to override the collaboration scheme. We are currently investigating the design of a comprehensive parameterized collaboration model that allows users and programmers to exercise control over the collaboration scheme by simply specifying values of high-level collaboration parameters. Such a model would allow users to interactively and dynamically tailor the collaboration scheme and programmers to write collaboration-aware code in a few minutes instead of a few days or weeks. We have developed a parameterized coupling model [13], which is based on the framework described here in that it associates coupling parameters with interaction variables, windows, and value groups. We are currently investigating parameterized concurrency control, access control, and undo/redo models that are similarly based on this framework. We are using our experience with developing our current set of multi-user applications to guide us in defining these parameters. Collaboration parameters are consistent with the idea of incremental awareness since they define an intermediate degree of collaboration awareness between collaboration transparency and awareness of the collaboration-aware primitives described here. Since single-user Suite is a high-level system, it supports a limited set of presentation schemes and userinterface commands in comparison to lower-level systems such as window systems and toolkits. In particular, it offers limited facilities for creating graphical displays and thus cannot, for instance, support a collaborative drawing tool such as Commune [36]. Therefore, it would be useful to apply aspects of our multi-user approach to lower-level systems and evaluate the practicality of this idea. Further study is also necessary to determine how the responsibilities of implementing collaboration functions should be divided among the various layers of an interactive system. One approach is to let every layer implement mechanisms for sharing of the interaction entities it defines and provide



38

mechanisms that can be used by higher-level layers to determine the policies on using the lower-level mechanisms. Further work is also needed to support high-level abstractions for supporting audio-based and video-based [35] collaboration. Riedl [45] describes an initial approach to offering audio-based collaboration in Suite. Finally, further work is also necessary to explore how a Suite-like system can support GroupKit-like overlays [46], MMM-like multi-user workstations [4], extensible message filtering rules such as those provided by Object Lens [30], decision support and negotiation support modules such as SCS [26] and Coop [44], and multi-user hypertext systems such as ABC [52], Hyper-G [7], and Trellis [54]. Finally, further work of the kind reported in [42] and [16] is necessary to identify (a) which of the various design decisions taken by our work and related works on multi-user frameworks are fundamental principles that any multi-user framework must support and (b) the relationships among principles of designing singleuser and multi-user frameworks. In conclusion, this paper makes the following main contributions: It identifies a new set of requirements for a multi-user framework including dynamic binding, user-interface independence, concurrent scheduling, error independence, flexible placement, and incremental awareness. It motivates, describes, and illustrates a framework that meets all of these requirements. The framework contains several novel components including a refinement of the Seeheim UIMS architecture that explicitly addresses multi-user interaction; the abstractions of shared active variables and interaction variables; a set of default collaboration rules designed to keep the collaboration-awareness low in multi-user applications; and a small but powerful set of collaboration-aware primitives that allow programs to demultiplex output, multiplex input, invoke programs in users’ environments, couple corresponding interaction entities, and offer access control, concurrency control, and collaboration-aware user-interfaces. It compares the framework with other multi-user frameworks, identifying the key similarities and differences among these systems. It discusses how aspects of our framework can be used to extend a variety of single-user interactive systems, showing that these aspects are more applicable to a high-level system rather than a low-level system and an asynchronous system rather than a synchronous system. Acknowledgments Several of the collaboration-aware primitives described here were motivated by the applications developed by Bret Lane, Vahid Mashayekhi, and John Riedl. Bret Lane implemented some of these primitives. REFERENCES

[1]

Robert A. Ballance, Susan L. Graham, and Michael L. Van De Vanter, ‘‘The Pan Language-Based Editing System for Integrated Development Environments,’’ Proc. of 4th ACM Symp. on Software Development Environments, December 1990, pp. 77-93.

[2]

Len Bass, Erik Hardy, Reed Little, and Robert Seacord, ‘‘Incremental Development of User Interfaces,’’ Proceedings of IFIP TC2/WG 2.7 Working Conference on Engineering for Human-Computer Interaction, Napa Valley, August 1989, North-Holland, 1990, pp. 155-176.



39

[3]

Michel Beaudoin-Lafon and Alain Karsenty, ‘‘Transparency and Awareness in a Real-Time Groupware System,’’ Rapport de Recherche no. 704, University de Paris-Sud Centre d’Orsay Laboratoire de Recherche en Informatique , October 1991.

[4]

Eric A. Bier and Steve Freeman, ‘‘MMM: A User Interface Architecture for Shared Editors on a Single Screen,’’ Proceedings of the 4th ACM SIGGRAPH Symposium on User Interface Software and Technology, November 1991, pp. 79-87.

[5]

R. Choudhary, ‘‘Undo/Redo in Collaborative User Interfaces,’’ Ph.D. Thesis Proposal, Purdue University, Department of Computer Science, October 1991.

[6]

Terrence Crowley, Paul Milazzo, Ellie Baker, Harry Forsdick, and Raymond Tomlinson, ‘‘MMConf: An Infrastructure for Building Shared Multimedia Applications,’’ Proc. of ACM Conference on Computer Supported Cooperative Work, October 1990, pp. 329-342.

[7]

G. Davies, H. Maurer, and J. Preece, ‘‘Presentation Metaphors for Very Large Hypermedia Systems,’’ Journal of Microcomputer Applications 14 (1991), pp. 105-116.

[8]

T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams, Dorset House Publishing Co., New York, 1987.

[9]

Prasun Dewan, ‘‘A Tour of the Suite User Interface Software,’’ Proceedings of the 3rd ACM SIGGRAPH Symposium on User Interface Software and Technology, October 1990, pp. 57-65.

[10]

Prasun Dewan and Eric Vasilik, ‘‘An Object Model for Conventional Operating Systems,’’ Usenix Computing Systems 3:4 (Dec 1990), pp. 517-549.

[11]

Prasun Dewan and Marvin Solomon, ‘‘An Approach to Support Automatic Generation of User Interfaces,’’ ACM Transactions on Programming Languages and Systems 12:4 (October 1990), pp. 566-609.

[12]

Prasun Dewan and Rajiv Choudhary, ‘‘Primitives for Programming Multi-User Interfaces,’’ Proceedings of the 4th ACM SIGGRAPH Symposium on User Interface Software and Technology, November 1991, pp. 6978.

[13]

Prasun Dewan and Rajiv Choudhary, ‘‘Flexible User Interface Coupling in Collaborative Systems,’’ Proceedings of the ACM CHI’91 Conference, April 1991, pp. 41-49.

[14]

Prasun Dewan, ‘‘An Inheritance Model for Supporting Flexible Displays of Data Structures,’’ Software— Practice and Experience 21:7 (July 1991), pp. 719-738 .

[15]

Prasun Dewan, ‘‘Flexible Coordination in Collaborative Software Engineering,’’ Proceedings of the NSF Workshop on Coordination Theory and Collaboration Technology, June 1991, pp. 41-48.

[16]

Prasun Dewan, ‘‘Principles of Designing Multi-User User Interface Development Environments Languages,’’ Proceedings of the IFIP TC2/WG 2.7 Working Conference on Engineering for Human-Computer Interaction, Ellivuori, Finland, August 1992.

[17]

Prasun Dewan, ‘‘Designing and Implementing Multi-User Applications: A Case Study,’’ Software-Practice and Experience 22:12 (December 1993).

[18]

Janet Drake, Vahid Mashayekhi, John Riedl, and Wei-Tek Tsai, ‘‘A Distributed Collaborative Software Inspection Tool: Design, Prototype, and Early Trial,’’ Proceedings of the 30th Aerospace Sciences Conference, January 92.



40

[19]

Clarence A. Ellis, Simon J. Gibbs, and Gail L. Rein, ‘‘Groupware: Some Issues and Experiences,’’ CACM 34:1 (January 1991), pp. 38-58.

[20]

D.C. Engelbart, ‘‘NLS Teleconferencing Features,’’ Proceedings of Fall COMPCON, September 1975, pp. 173-176.

[21]

J.R. Ensor, S.R. Ahuja, D.N. Horn, and S.E. Lucco, ‘‘The Rapport Multimedia Conferencing System: A Software Overview,’’ Proceedings of the 2nd IEEE Conference on Computer Workstations, March 1988, pp. 52-58.

[22]

James Foley, Won Chul Kim, Srdjan Kovacevic, and Kevin Murray, ‘‘Defining User Interfaces at a High Level of Abstraction,’’ IEEE Software, January 1989, pp. 25-36.

[23]

Christopher W. Fraser, ‘‘Syntax Directed Editing of General Data Structures,’’ Proceedings of the ACM SIGPLAN SIGOA Symposium on Text Manipulation, SIGPLAN Notices 16:6 (June 1981).

[24]

C.W. Fraser and D.R. Hanson, ‘‘High-Level Language Facilities for Low-Level Services,’’ Conference Record of POPL, 1985, pp. 217-224.

[25]

Phil Gust, ‘‘Shared X: X in a Distributed Group Work Environment,’’ Presented at the Second Annual X Technical Conference, MIT, January 1988 .

[26]

Matti Hamalainen, Safaa Hashim, Clyde W. Holsapple, Yongmoo Suh, and Andrew B. Whinston, ‘‘Structured Discourse for Scientific Collaboration,’’ Journal of Organizational Computing, to appear.

[27]

G. Hamlin and J. Foley, ‘‘Configurable Applications for Graphics Employing Satellites (CAGES),’’ Computer Graphics 9:1 (Spring 1975), pp. 9-19.

[28]

Scott E. Hudson and Roger King, ‘‘A Generator of Direct Manipulation Office Systems,’’ ACM Transactions on Office Information Systems 4:2 (April 1986), pp. 132-163.

[29]

Dan R. Olsen Jr., Thomas G. McNeill, and David C. Mitchell, ‘‘Workspaces: An Architecture for Editing Collections of Objects,’’ ACM CHI’92 Proceedings, May 1992, pp. 267-272.

[30]

K-Y. Lai and T.W. Malone, ‘‘Object Lens: A Spreadsheet for Cooperative Work,’’ Proceedings of 1988 Conference on Computer Supported Cooperative Work, 1988.

[31]

Keith A. Lantz and William I. Nowicki, ‘‘Structured Graphics for Distributed Systems,’’ ACM Transactions on Graphics 3:1 (January 1984), pp. 23-51.

[32]

Keith A. Lantz, ‘‘An Experiment in Integrated Multimedia Conferencing,’’ Proceedings of Conference on Computer-Supported Cooperative Work, December 1986, pp. 267-275.

[33]

J.C. Lauwers and K.A. Lantz, ‘‘Collaboration Awareness in Support of Collaboration Transparency: Requirements for the Next Generation of Shared Window Systems,’’ Proceedings of ACM CHI’90, April 1990, pp. 303-312.

[34]

Mark A. Linton, John M. Vlissides, and Paul R. Calder, ‘‘Composing User Interfaces with InterViews,’’ IEEE Computer, February 1989, pp. 8-24.

[35]

M. Mantei, R. M. Backer, A. J. Sellen, W. A.S. Buxton, T. Milligan, and B. Wellman, ‘‘Experiences in the Use of a Media Space,’’ Proceedings of CHI’91, April 1991, pp. 203-208.

[36]

S. L. Minneman and S. A. Bly, ‘‘Managing a trois: A Study of a Multi-User Drawing Tool in a Distributed Design Work,’’ Proceedings of CHI’91, April 1991, pp. 217-224.



41

[37]

M. Morgenstern, ‘‘Active Databases as a Paradigm for Enhanced Computing Environments,’’ Proceedings of the 9th International Conference of Very Large Data Bases , 1983, pp. 34-42.

[38]

R. E. Newman-Wolfe, C. L. Ramirez, H. Pelimuhandiram, M. Montes, M. Webb, and D. L. Wilson, ‘‘A Brief Overview of the DCS Distributed Conferencing System,’’ Proceedings of the Summer Usenix Conference, June 1991, pp. 437-452.

[39]

Teresa L. Nixon, Kara Lubenow, Jagannathan Srinivasan, Prasun Dewan, and Bharat Bhargava, ‘‘Building a User-Interface for the O-Raid Database System using the Suite System,’’ Proceedings of the ’92 IEEE International Conference on Systems Integration, June 1992.

[40]

David Notkin, ‘‘Interactive Structure-Oriented Computing,’’ Ph.D. Thesis and Technical Report, CMU-CS84-103, Department of Computer Science, Carnegie-Mellon University, February 1984.

[41]

John F. Patterson, Ralph D. Hill, Steven L. Rohall, and W. Scott Meeks, ‘‘Rendezvous: An Architecture for Synchronous Multi-User Applications,’’ Proceedings of the Conference on Computer-Supported Cooperative Work, October 1990, pp. 317-328.

[42]

John F. Patterson, ‘‘Comparing the Programming Demands of Single-User and Multi-User Applications,’’ Proceedings of the 4th ACM SIGRAPH Conference on User Interface Software and Technology, November 1991, pp. 79-86.

[43]

G. Pfaff, User Interface Management Systems, Springer Verlag, Englewood Cliffs, NJ, 1985.

[44]

C.V. Ramamoorthy and S. Shekhar, ‘‘A Cooperative Approach to Large Knowledge Based Systems,’’ Proceedings of Sixth IEEE International Conference on Data Engineering, February 1990, pp. 346-352.

[45]

J. Riedl and V. Mashayeki, ‘‘Continuous Media in Discrete Objects: Multimedia for Computer Supported Collaborative Work,’’ Proceedings of 1992 Workshop on Multimedia Information Systems, February 1992.

[46]

Mark Roseman and Saul Greenberg, ‘‘GroupKit: A Groupware Toolkit for Building Real-Time Conferencing Applications,’’ Proceedings of the ACM Conference on Computer Supported Cooperative Work, to appear in November 1992.

[47]

L. C. Rosenberg, ‘‘Update on National Science Funding of the ‘‘Collaboratory’’,’’ CACM 34:12 (December 1991).

[48]

Sunil Sarin and Irene Greif, ‘‘Computer-Based Real-Time Conferencing Systems,’’ IEEE Computer 18:10 (October 1985), pp. 33-49.

[49]

R.W. Scheifler and J. Gettys, ‘‘The X Window System,’’ ACM Transactions on Graphics 16:8 (Aug. 1983), pp. 57-69.

[50]

Jeffrey Scofield, ‘‘Editing as a Paradigm for User Interaction,’’ Ph.D. Thesis and Technical Report No. 8508-10, University of Washington, Department of Computer Science, August 1985.

[51]

John L. Sibert, William D. Hurley, and Teresa W. Blaser, ‘‘An Object-Oriented User Interface Management System,’’ Computer Graphics 20:1 (February 1986).

[52]

John B. Smith and F. Donelson Smith, ‘‘ABC: A Hypermedia System for Artifact-Based Collaboration,’’ Proceedings of the Third ACM Conference on Hypertext, December 1991.

[53]

Mark Stefik, Gregg Foster, Daniel G. Bobrow, Kenneth Kahn, Stan Lanning, and Lucy Suchman, ‘‘Beyond the Chalkboard: Computer Support for Collaboration and Problem Solving in Meetings,’’ CACM 30:1 (January 1987), pp. 32-47.



42

[54]

P. David Stotts and Richard Furuta, ‘‘Dynamic Adaptation of Hypertext Structure,’’ Proceedings of the Third ACM Conference on Hypertext, December 1991.

[55]

J. Sutton and R. Sprague, ‘‘A Study of Display Generation and Management in Interactive Business Applications,’’ Tech. Rept. RJ2392(#31804), IBM San Jose Research Laboratory, November 1978.

A High-Level and Flexible Framework for Implementing ... - CiteSeerX

A High-Level and Flexible Framework for Implementing ... - CiteSeerX

Suggest Documents

A High-Level and Flexible Framework for Implementing Multi-User ...

A Flexible Framework for Implementing Software ... - Brown CS

Harmonia: A Flexible Framework for Constructing ... - CiteSeerX

implementing a sustainable livelihoods framework for ... - CiteSeerX

VOtus: A Flexible And Scalable Monitoring Framework for ... - CiteSeerX

A Flexible Framework for Key Audio Effects Detection and ... - CiteSeerX

OverSim: A scalable and flexible overlay framework for ... - CiteSeerX

DIFFRAC : a discriminative and flexible framework for ... - CiteSeerX

a framework for assessing and implementing cloud

Implementing a Flexible Compensation Mechanism for Business ...

A Flexible Object Merging Framework - CiteSeerX

FLEXIBLE PRODUCTION CONTROL - A FRAMEWORK ... - CiteSeerX

Implementing Flexible Computation Rules with ... - CiteSeerX

ManIPA: A flexible Manipulation Framework for Collision ... - CiteSeerX

A Flexible Topic-driven Framework for News Exploration - CiteSeerX

A Flexible Framework for Evaluating the Socio-Cultural ... - CiteSeerX

A Flexible QoS Framework for Cluster-based Network ... - CiteSeerX

A Framework for Implementing Pluggable Type Systems - CiteSeerX

Implementing a Trauma Recovery Framework for Youths ... - CiteSeerX

A framework for implementing reusable digital signal ... - CiteSeerX

OpenStructure: a flexible software framework for computational ...

A flexible framework for defeasible logics

A Flexible, Interoperable Framework for Active ...

A Flexible Formal Verification Framework for