Building Real-Time Groupware with
`GroupKit, A Groupware Toolkit
`
`MARK ROSEMAN and SAUL GREENBERG
`University of Calgary
`
`This article presentsan overview of GroupKit, a groupware toolkit that lets developersbuild
`applications for synchronous and distributed computer-based conferencing. GroupKit was
`constructedfrom our belief that programminggroupwareshould be only slightly harder than
`building functionally similar single-user systems. We have been able to significantly reduce
`the implementationcomplexity of groupware through the key features that comprise Group-
`automatically manages the creation, interconnection, and
`Kit. A runtinw infia.structure
`communications of the distnbutsd processes that comprise conference sessions. A set of
`allows developersto control the behavior of distributed
`groupware
`programming
`abstractions
`processes,to take action on state changes, and to share relevant data. Groupwarewidgets
`let
`interface features of value to conference participants to be easily added t.a groupware
`applications. Session managers —interfaces that let people create and manage their meet-
`inge—aredecoupledfrom groupwareapplicationsand are built by developersta accommodate
`the group’s working style. Example GroupKit applicationsin a variety of domains have been
`implementedwith only modest effort.
`Categories and Subject Descriptors:D.2.2 [Software Engineering]: Tools and Techniquee—
`Languages]: LanguageConstmcts and Features;D.4.1
`user inte~aces; D.3.3 [Programming
`[Operating Systems]: Organization and Design-interactive systems;H.5.2 [Information
`Interfaces
`and Presentation]:
`User Interfaces-user
`interface management
`systems; H.5.3
`and presentation]: Group and OrganizationInterfaces-synchro-
`[Information
`Interfaces
`nous interaction
`General Terms: Human Factors
`Additional Key Words and Phrases: Computer-supportedcooperative work, GroupKit, group-
`ware toolkits,
`synchronous
`groupware,
`user interface
`toolkits
`
`INTRODUCTION
`1.
`Over the last few years, we have been designing groupware for synchronous
`distributed conferencing, where two or more
`distance-separated
`people
`work
`on a shared
`task
`in real
`time. Our
`first
`system,
`called
`Share
`[Greenberg
`19901, allovved participants
`in a distributed meeting
`to take
`
`Sciences
`
`and Engineering
`
`Research
`
`in part by the National
`supported
`research was
`This
`Council
`of Canada and by Intel Corporation.
`Science, University
`Authors’
`address: Department
`of Computer
`T2N 1N4, Canada;
`email:
`[roseman;
`saul]@cpsc.ucalgary
`.ca.
`or classroom use
`Permission
`to make digital/hard
`copy of part or all of thie work for personal
`is granted without
`fee provided
`that
`the copies are not made
`or distributed
`for profit
`or
`commercial
`advantage,
`the copyright notice,
`the title of the publication,
`and its date appear,
`of the ACM, Inc. To copy otherwise, to
`and notice
`ie given that
`copying
`is by permission
`republieh, to post on servers, or to redistribute to lists, requires prior specific permission
`and/or a fee.
`@ 1996ACM 1073-0516/96/0300-0066$03.50
`
`of Calgary, Calgary, Alberta
`
`ACM Transactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996, Pages 66-106.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 001
`
`

`

`GroupKit, a Groupware Toolkit
`
`.
`
`67
`
`Table I. Core Requirements
`
`for a Groupware Toolkit
`
`Design Requirement
`User Cerriered
`
`Rationale
`
`Examples
`
`lTele~inters
`Support multiuser Many groupware applications can be seen as
`shared work surfaces, and stttdies (e.g., Tang lGraphicsdAnnotations
`actions and
`awareness of
`[1991], Gutwin and Greenberg [1995], and
`lMuhiuser Scrolkrars
`lGestalt Views
`Dourish and Bellotti [1992]) have attemptedto
`others over a
`visual work
`cbaracteti
`some of tfte properties necessaryto
`surface.
`support collaborativework. .%q.prdng tkse in
`a toolkit can encourage developers to build more
`usable applications.
`
`Provide stqymrt
`for structuring
`group processes
`but do so in a
`flexible enough
`fashion to accom-
`modatethedlversc
`needs of different
`groups.
`
`Rather than adopt a single model for how groups Different Polia”esfor:
`should interact, a toolkit should provide a range
`.Floor Control
`l-ion M~~
`of facilities to support the needa and working
`styles of different groups, while allowing appli-
`.Acceaa to Conferences
`cation develops
`to extend these to support spe-
`.Treatrnent of Latemmera
`cific steeds[Greenberg 1591]. A toolkit should
`scs~rt buildhtg ap@icationsrelying on either
`aocmtprotocols orhrghly stmctured andautomated
`proceaa models.
`
`Integrate group-
`warewith
`conventional
`ways of doing
`work.
`
`.Shared Terminals
`shouldnotpme a barria to ‘Wvidual”
`-are
`lTe@hone Links
`waysof doing work, but instead it should be
`antooUdyintegrated [ItiI andKotsayashi19%2]..Videa Conferencirsg
`Access to both single-user applications or even
`aoncomputer reaortrces [Iabii 195X)]is important,
`as is the avaiiabifityof traditiorudcommunication
`rne&srns.
`Programmer Centered
`
`Provide technical Groupware systems are composedof multiple
`lSession Management
`support to deal
`processes that mmsnurricateover a network,
`l process Creation
`with multiple
`and toolkits can augment the operating-system-
`l Locate Other Processes
`distributed
`level support by simplifyhrg creation, inter-
`.Multicaat Abstractions
`comection, and teardown of the processes. A W%aion Persistence
`proceaaes.
`toolkit can also provide cmntnuntcations models lMeaaage SdsLzstion
`ami concurrencycontrol smclsartismathat abstract
`and Data LQcking
`away from the operating system.
`
`Provide support
`for shared data.
`
`Dim-ibutedgroupware shouldalso be able to share lShared Environments
`its commondata easily and shmddbe able to &lezt lData serialization
`and take action when data are changed. Concar-
`and LOCking
`lBirtchtg Caflbacks to
`rency control should b available to kee data
`consistent [Greenberg ad Marwood 1 4].
`!?!
`Environment Events
`
`Provide support
`for shared data
`and an extensible
`shared-gmphics
`model.
`
`Iicatioas can k seen lSbared Graphics
`Sin@ many groupware
`as shared visual work au aces, a toolkit ahoutd
`and Primitives
`??
`supportthecreationandrtsanipulatkmof bothgemric K)bj@_-
`ad qsplication-specificobjectson a graphicalwork
`surface. paradigmssuch as Abs&acdon-Link-View lSepamteView fmar
`[Patterson 1991]can be supported by the toolkit
`Objezt Representation
`to facilitate this.
`
`was
`group interaction
`applications;
`single-user
`unaltered
`sharing
`turns
`floor
`control mechanisms
`of flexible
`mediated
`by choosing
`from a variety
`to best match the particular
`style of the meeting
`[Greenberg
`1991]. We
`then built
`several
`groupware
`equivalents
`of paint and structured
`draw-
`ing programs
`[Greenberg
`et al. 1992]. GroupSketch
`was a minimalist
`bitmapped
`sketchpad, where
`all users
`saw exactly
`the same
`things
`on
`their display, FMwell as the multiple pointers of other participants. X/Group-
`Sketih was a second-generation
`version that, among its additional
`features,
`
`‘
`
`ACM Transactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 002
`
`

`

`68
`
`l
`
`M. Roseman and S. Greenberg
`
`allowed participants to view different parts of the document. GroupDraw was
`a prototype of a structured drawing application, where participants could
`jointly manipulate a variety of objects, such as lines and rectangles, on their
`display.
`Building groupware proved a frustrating experience. Implementing even
`the simplest systems was a lengthy process, as much time was
`spent
`inventing
`similar
`ideas over and over again. Some of the common tasks of
`the programmer
`included
`the following
`items. The setup and management
`of distributed
`processes
`had to be arranged.
`Interprocess
`communication
`links had to be established.
`Actions
`between
`processes
`had to be coordi-
`nated
`and their
`internal
`states updated
`as people
`interacted
`with the
`system. Similar
`interface
`components
`had to be reimplemented
`to provide
`for generic
`group needs. Session managers
`had to be supplied
`so that
`people could create, monitor,
`and enter
`the conferences.
`to support
`toolkit
`Consequently,
`we decided h implement
`a groupware
`programming
`of synchronous
`and distributed
`computer-based
`conferencing
`systems. Our motivation
`for this project was our belief
`that:
`
`A developer using a well-designed toolkit should find it only slightly
`the
`harder to program usable groupware systems when compared to
`effort required to program an equivalent single-user system.
`
`We took the tasks common
`(noted
`programming
`all groupware
`to almost
`earlier)
`and transformed
`them into a set of core user and programmer-
`in
`centered
`requirements
`for a groupware
`toolkit. These are summarized
`Table 1 and are described
`in more detail elsewhere
`[Roseman
`and Green-
`berg
`19921. The table
`also lists
`the rationale
`behind
`the requirements.
`From these
`requirements,
`we believed
`that a tiolkit
`could reduce
`imple-
`mentation
`complexity
`by providing
`the following
`generic
`features:
`
`and man-
`
`infrastructure would automatically create processes
`—A runtime
`age their interconnections
`and communications.
`built on top of a
`—A simple set of groupware
`programming
`abstractions,
`conventional
`language and GUI toolkit, would be available to groupware
`developers. Primitives would include remote
`procedure
`calls between
`application
`instances,
`sharing
`of data, and generation
`and tracking
`of
`conferencing
`events.
`widgets would let developers easily add generic
`—A set
`of groupware
`interface constructs
`of value
`to conference
`participants,
`resulting
`in
`better and more usable groupware
`systems.
`the mechanism by which people create and manage
`-Session
`management,
`meetings, would be handled separately
`from the groupware
`applications.
`Primitives
`for constructing
`different
`session managers would be available
`for developers wishing
`to create custom interfaces
`that suit the particu-
`lar needs of a group.
`
`The result of our efforts
`a toolkit whose design has been
`is GroupKit,
`evolving
`over several years. The first generation
`of GroupKit,
`developed
`in
`
`ACM Transactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 003
`
`

`

`GroupKit, a Groupware Toolkit
`
`l
`
`69
`
`C++ and InterViews [Linton et al, 1989], has been described in a previous
`paper
`[Roseman
`and Greenberg
`1992]. Based on our experiences with that
`system, we constructed
`a second-generation
`version that has proven to be
`an even richer platform for developing
`groupware.
`Readers
`familiar with
`the earlier work should find that
`the version described
`here both general-
`izes and extends
`the earlier
`system.
`under an
`GroupKit
`and its applications
`still run on Unix workstations
`Xl 1 environment.
`However,
`the
`system now uses
`the
`interpreted
`Tcl
`language
`and Tk interface
`toolkit
`[Ousterhout
`1994] and the Tc1-DP socket
`extensions
`[Smith et al. 1993]. GroupKit
`developers
`build their applications
`using Tcl/Tk as well as the extensions
`provided
`by our toolkit. GroupKit
`and the underlying
`systems
`are all
`freely
`available
`via anonymous
`ftp;
`details are provided
`at the end of this article. 1
`It shows both how an
`The article begins with an overview of GroupKit.
`and what a GroupKit
`end-user
`sees systems
`constructed with the toolkit
`program looks
`like. Subsequent
`sections
`detail GroupKit’s
`features—its
`runtime
`infrastructure,
`its groupware
`programming
`abstractions,
`the set of
`groupware widgets,
`and its session management.
`These sections
`show how
`some of these features work in practice by including
`both screen snapshots
`and code fragments
`from existing applications.
`The examples
`also illustrate
`the wide variety of systems
`that can be built
`in GroupKit. The article then
`evaluates GroupKit
`by examining
`the effort
`required
`to build groupware
`applications
`in it.
`It closes
`by comparing
`GroupKit
`to other groupware
`toolkits. A video
`is also available
`[Greenberg
`and Roseman
`1994]
`that
`captures
`the dynamics
`of many of the screen snapshots
`described
`in this
`article.
`
`2. OVERVIEW
`Before delving into technical
`for
`feel
`an overall
`it is worth getting
`details,
`this section begins by showing what end-users
`GroupKit. To set the scene,
`of programs
`built
`in GroupKit may see. It then takes the developer’s
`view,
`by tracing
`through a simple GroupKit
`program.
`are running X Windows
`The scenarios
`presume
`that users’
`computers
`are
`interconnected
`using
`within
`a Unix
`environment,
`that
`computers
`the GroupKit
`software
`has
`TCP/IP protocol
`over
`the Internet,
`and that
`on the lnternet
`as long as
`been installed. Users may be located anywhere
`their network
`connection
`does not suffer
`excessive
`latency
`(which would
`compromise
`interactive
`performance
`of some applications).
`Because Group-
`Kit
`can run in most Unix
`systems,
`the actual machine
`type does not
`matter.z
`
`of
`are under active development, with new versions
`that comprise GroupKit
`‘ All the systems
`software
`appearing
`periodically.
`This article
`is mostly based upon GroupKit
`3.1, Tcl 7.4, Tk
`4.0, and Tc1-DP 3.2.
`installed
`has been successfully
`z For example, GroupKit
`Graphics workstations
`as well as PCs running Linux.
`
`on Sun, HP, RS6000, and Silicon
`
`ACM Transactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 004
`
`

`

`70
`
`l
`
`M. Roseman and S. Greenberg
`
`(%tmmi?S
`
`w&@Rms
`
`Design Sasslal
`
`I.Ma TmI$ctnw
`(M Gulwln
`
`Yuu an% Isaul Greenberg
`
`Fig. 1. The Open Registration session manager: two conference sessions are shown, with
`three participantspresent in the PostIt conference.
`
`2.1 An Example of an End-User’s View of GroupKit
`This section walks through an example GroupKit
`session, where we will see
`two existing
`conferences,
`a user monitoring
`conferences
`in progress,
`joining
`the scenario
`illustrates
`and then creating
`a new conference.
`Although
`it is important
`to remem-
`actual systems provided in the GroupKit
`release,
`ber that
`these are just examples
`of systems
`that programmers
`could build
`with the toolkit.
`in this case the “Open
`a session manager,
`invokes
`First,
`the user (Saul)
`pane, Saul sees that
`(Figure 1). In the “Conferences”
`Registration” manager
`two conferences
`are in progress:
`“PostIt” and “Design Session.” By selecting
`one of them, he can then see who is in a particular
`conference
`(the list in
`the “Participants”
`pane).
`its name,
`clicking
`by double
`conference
`Next, Saul
`joins
`the “Postlt”
`The PostIt Editor
`then appears
`which adds him to the list of participants.
`on his display
`(Figure
`2, left window). With this simple GroupKit
`applica-
`tion, he can type a short message
`and send it to one or more participants.
`The selected participants will see the message
`appear
`in a pop-up window.
`In Saul’s work community,
`everyone uses PostIt
`to see who is available
`and
`to invite
`people
`into
`conferences.
`Shortly
`after
`joining,
`Saul
`receives
`a
`PostIt message
`from Linda
`inviting
`him to join the
`“Design
`Session”
`conference
`(Figure 2, right window).
`and
`via the session manager,
`Saul
`joins
`the “Design Session”
`conference
`then
`GroupSketch,
`a multiuser
`sketchpad that allows simultaneous
`drawing,
`appears on his display (Figure 3). lt contains the group drawing being worked
`on, as well as the teleprinters
`of the other participants. The voice connection is
`made through a telephone
`conference
`call. ~er
`discussing
`the figure, Saul
`leaves the conference by selecting the “Quit” option from the “File” menu.
`A bit later on, Saul receives
`a phone
`call
`from his colleague
`Judy, who
`wishes
`to discuss a document.
`Saul decides
`to create a new conference
`that
`runs the FileViewer.
`This application
`provides
`a relaxed what-you-see-is-
`
`ACM Transactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996,
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 005
`
`

`

`GroupKit, a Groupware Toolkit
`
`l
`
`71
`
`(l’hu Feb S16#1211SSS)
`
`Hey, Saul. can you join the Design Session?
`We have some ideas for the figure you
`wanted...
`
`Our conference
`220-6067
`w q;.l;$yx;~c?
`
`&
`
`call phone number
`
`is
`
`5+.- ,:*.*,
`
`k.rti
`
`S.,.
`
`*9
`
`.
`
`r YOIIXSCH
`
`r M6rk ROSUXMII
`I_ LindaTauschcr
`r cdchmh
`
`, ~
`
`clearNote
`
`. .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`,
`
`~
`
`Rsautl
`
`Fig. 2. The PostIt application:
`PostIt Note.
`
`notes are created through the PoatIt Editor and received as a
`
`what-I-see (WYSIWIS) view of a text document3 and displays multiuser
`scroll bars showing what each person is able to see. From the “Conferences”
`pull-down menu in the session manager
`(Figure
`1), he selects
`“File Viewer”
`from the many applications
`listed, which adds its name to the Conferences
`pane in every session manager. FileViewer
`appears
`on his display,
`and he
`then selects a file to view in it. Judy joins the conference,
`and they continue
`their discussion
`around the shared view (Figure 4).
`This scenario
`illustrates
`several
`important
`points about GroupKit.
`
`—GroupKit supports real-time distributed multipoint conferences between
`many users.
`for managing confer-
`both session managers
`include
`—GroupKit
`systems
`such as the Open Registration system in Figure
`1, and confer-
`ences,
`which are the actual groupware
`tools, as shown by
`ence applications
`the PostIt, GroupSketch, and FileViewer applications
`in Figures
`2, 3,
`and 4.
`the
`that match
`session managers
`can build
`designers
`—Groupware
`The “Open Regis-
`and organization.
`styles
`of their audience
`working
`is one
`that
`presents
`a free-for-all
`system illustrated
`here
`tration”
`on session management;
`other
`examples
`are presented
`later
`policy
`this article.
`—GroupKit
`is a generic
`
`in
`
`applica-
`
`toolkit,
`
`in that a variety
`
`of conference
`
`9In strictWYSIWISsystems, all users see exactly the same thing on their displays,
`In relaxed
`WYSIWIS,
`users may have different
`viewports
`into the shared workspace
`andlor different
`representations
`of their contents
`[Stefik et al. 1987].
`
`ACM Transactions on Computer-Humsn Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 006
`
`

`

`72
`
`l
`
`M. Roseman and S. Greenberg
`
`sketching
`Fig. 3. The GroupSketch multiuser
`cursor, and two remote teleprinter widgets.
`
`application,
`
`showing the shared drawing,
`
`local
`
`m
`3.0 relies
`OroupKlt
`each of
`these
`inetall
`FA9, posted
`regularly
`point
`you in the right
`
`~~
`Obtain and
`‘IX3. 6, and Tcl-DP3. 2.
`on Tc17, 3,
`the Tcl
`(for
`assistance
`coneult
`packages
`to comp. lang.
`tcl,
`or
`contact
`ua and ve’ I.1
`direction)
`
`unpack QroupKit
`Run the conf@ure
`for
`your ayetem.
`
`TCL Z% and Tcl-
`containing
`srme directory
`from the
`to create
`a Ifakaflle
`eultable
`ecrlpt
`6roupXit
`If you plan on installing
`
`anyvhere
`
`other
`
`H
`
`m
`
`[W
`
`Fig. 4.
`widget.
`
`The FileViewer
`
`relaxed WYSHNIS
`
`application,
`
`showing
`
`the multiuser
`
`scrollbar
`
`can be built. Other
`or graphics
`text
`on either
`relying
`tions
`in later
`sections.
`are illustrated
`applications
`believe
`we strongly
`space
`system. Although
`is not a media
`—GroupKit
`real-time
`interaction,
`is necessary
`for most
`communication
`that voice
`support
`audio
`or video
`conferencing.
`For
`does not directly
`GroupKit
`now, we expect users to use other
`systems,
`such as telephones. Option-
`ally, an application programmer
`could have GroupKit automatically
`invoke
`an external
`computer-based
`audio/video
`system as a GroupKit
`conference
`whenever a conference
`connection is made.4
`
`example
`
`4GroupKit could be extended to provide direct multimedia communications. We decided
`against this because: (a) we did not have the resources to duplicate existing work in media
`spaces; (b) it would make GroupKit both platform and hardware dependent;(c) GroupKit’s
`
`ACM Transactions on Computer-Humsn Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 007
`
`

`

`GroupKit, a Groupware Toolkit
`
`.
`
`73
`
`2.2 A Developer’s View of GroupKit: An Example Program
`The preceding
`section illustrated what an end-user
`of GroupKit may see.
`This section presents
`an application
`developer’s
`point of view, by walking
`through
`a complete
`groupware
`application
`called
`“hello world.”
`Even
`though it is a simple
`example
`(in keeping with its genre),
`it is far from
`trivial. Not
`only does
`it demonstrate
`several
`important
`GroupKit
`con-
`structs,
`it is probably
`the only “hello world”
`program that actually
`says
`hello to the world!
`runs his or her own copy
`conference
`in a “hello world”
`Every participant
`of the program. Each person sees a window on his or her screen containing
`5, top). When any user presses the
`a button labeled “Hello World”
`(Figure
`button,
`the buttons on all participants’
`screens are changed to display
`briefly a greeting from the user who pressed the button. For example,
`if
`Mark Roseman pressed the button, all participants would see “Mark
`Roseman says hello!” (Figure 5, bottom).
`To create this GroupKit conference,
`the application programmer would
`need to write a program similar to that shown in the following code. Most of
`the code is standard Tcl/Tk concerned with providing the user interface;
`only the parts in bold signify the GroupKit
`code needed to make the
`program group-aware.
`
`1
`2
`3
`4
`5
`
`$argv
`gk.initConf
`.menubar
`gk.defaultMenu
`-side top -fill x
`pack .menubar
`set greetings “[users Iocal.uaemame]
`button hello -text “Hello World” \
`-command “gk-toAll
`pack hello -side top
`{
`proc say-hi
`{new-label}
`hello configure -text $new–-label
`after 2000 (hello configure -text “Hello World”}
`
`says hello!”
`
`say–hi Y$greetingsY”
`
`6
`7
`8
`9
`10
`}
`Line 1 initializes the application and asks GroupKit’s runtime architec-
`ture to automatically manage such things as maintaining socket connec-
`tions between this local process and the copies being run on the other
`participants’ workstations.
`that provides
`Line 2 creates GroupKit’s default menu bar, a widget
`access to some generic groupware facilities (other widgets are discussed in
`Section 5). It gives the participant
`the ability to leave the conference
`gracefully (a “Quit” option in the File menu),
`lets them see what other
`conference participants are present (a “Participants” option in the Collabo-
`ration menu), and provides access to help topics (the Help menu). Line 3
`calls the standard Tk function that places the widget at the top of the
`window.
`
`compromise;
`systems appeared to be a reasonable
`ability to invoke existing online audio/video
`and (d) the telephone
`company
`already supplies an excellent audio channel, which suffices
`for
`many situations.
`
`ACM Transactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 008
`
`

`

`74
`
`.
`
`M. Roseman and S. Greenberg
`
`L gk_toAU “say_hi
`
`Fig. 5. The Hello World application running on two displays. The sequence of eventa shows
`the procedure“say-hi” being multicast to all replicated processes.
`
`In line 4, we create a string (called greetings)
`that will serve as a message
`from the local participant,
`e.g.,
`“Mark Roseman says hello!” This line
`queries a special data structure provided by GroupKit called an erzvirorz-
`ment that maintains information about local and remote users. In this case,
`the code within the square brackets asks the environment
`to return the
`name of the local user, which is used to construct the string. Environments
`have other features and are discussed further in Section 4.3.
`Lines 5-6 create a standard Tk button, initially giving it the label “Hello
`is attached to it as a callback and is
`World.” The GroupKit function gk–toAll
`executed when the button is pressed by the user. This procedure is a
`(Section 4.1) that arranges for other func-
`nudticast remote procedure
`call
`to be executed not only on the
`tions (in this case the procedure say–hi)
`workstation where the button was pushed, but on the workstation of every
`user in the session. This sequence is illustrated in Figure 5.
`Finally,
`lines 7–10 contain the say–hi procedure. Line 8 changes the
`button’s label to contain the procedure’s argument (the greetings), and line
`9 changes
`it back to “Hello World” after two seconds. When gk-toAll
`the procedure execution, each person’s display will show the
`multicasts
`same greetings message, as illustrated in Figure 5.
`If we wanted to make this example slightly more sophisticated, we could
`add the following lines to the end of the program. This would automatically
`change the button’s text whenever a new user enters into the conference;
`for example, “Saul Greenberg just arrived!” would be displayed.
`
`1-10
`11
`12
`13
`14
`
`as above
`{
`newUserArrived
`gk-bind
`set new–user-name [users remote. ”AU.usemame]
`say-hi “$new-user-name
`just arrived!”
`
`}
`
`ACM ‘1’ranaactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 009
`
`

`

`GroupKit, a Groupware Toolkit
`
`l
`
`75
`
`These extra lines illustrate how developers can take advantage of events
`that are automatically
`generated
`by GroupKit. Here,
`the developer
`asks
`that some code be automatically
`executed whenever
`a new user enters
`the
`as indicated by the newUserArrived event. In line 11, GroupKit’s
`conference,
`gk–bind command attaches the code on the next two lines as a callback to
`the newUserArrived event. When this event
`is triggered
`by the arrival
`of a
`new user,
`the code is executed locally. Line 12 will retrieve
`the name of the
`arriving user; in this case YoU indicates which user has arrived, and the
`environment query [users remote. ‘MoU. username] provides the name of that
`is now the
`user.5 Line 13 calls the say-hi procedure, whose argument
`onto the string “just arrived! .“ The
`arriving user’s name concatenated
`interaction between events and environments is discussed further in Sec-
`tions 4.2 and 4.3.
`Finally, the program is made available to the session manager by editing
`a configuration file. All that has to be specified here is a default conference
`name (e.g., Hello World) and the location of the program.
`This program, simple as it is, illustrates several
`important points about
`developing groupware in GroupKit.
`
`the conference through
`
`are decoupled from session manage-
`—GroupKit’s conference
`applications
`ment. The developer does not have to worry about creating new processes
`or managing communication connections.
`—Developers have access to information about
`data structure.
`GroupKit’s environments
`—Developers know that conference applications are executed as communi-
`cating replicated processes, one for each participant.
`—Developers
`can synchronize GroupKit
`conferences
`remote procedure
`calls.
`—GroupKit provides a suite of special groupware widgets which are easily
`attached to a groupware program. These widgets encapsulate tools useful
`to end-users.
`that allow them to
`—Developers can attach callbacks to groupware
`euents
`note and take action when, for example, people enter and leave confer-
`ences.
`
`through multicast
`
`As the parts in boldface of the preceding program suggest, doing the
`groupware “Hello World” program is only slightly harder than its equiva-
`lent single-user version.
`
`3. THE RUNTIME INFRASTRUCTURE
`One of the design requirements listed in Table I stated that a groupware
`toolkit should provide technical
`support
`for programmers dealing with
`multiple distributed processes. We believe this is best satisfied by including
`
`of gk–bind and its use of a % (field)
`for retrieving
`specification
`the syntax
`5 We designed
`information
`about events to be similar
`to Tk’s event-binding mechanism, making it familiar
`to
`Tcl/Tk programmers.
`
`ACM Transactions on Computer-Human Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 010
`
`

`

`76
`
`l
`
`M. Roseman and S. Greenberg
`
`A Wbll-Known”Workstation
`
`a.’
`
`Mary
`
`GeoI@s Wotkatation
`
`May’s Workstation
`
`Fig. 6. An example
`
`of GroupKit’s
`
`runtime process model.
`
`a runtime infrastructure that actively manages these processes. Its respon-
`sibilities would include: process creation,
`location,
`interconnection,
`and
`teardown; communications setup such as socket handling and multicasting;
`and groupware-specific
`features such as providing the infrastructure for
`session management and persistent conference sessions (Section 6). This
`section presents the actual runtime infrastructure supported by GroupKit.
`It describes the different
`types of processes GroupKit creates and main-
`tains and the interactions between them. Later sections introduce the
`programming abstractions supported by this infrastructure that are avail-
`able to developers.
`consists of a variety of distributed
`GroupKit’s runtime infrastructure
`processes arranged across a number of machines. Figure 6 illustrates an
`example of the processes running when two people are communicating with
`each other through two conferences A and B. The three large boxes
`represent three workstations;
`the ovals are instances of processes running
`on each machine; and the directed lines joining them indicate communica-
`tion paths. Three types of GroupKit processes are shown: registrar,
`session
`and conference
`managers,
`applications.
`
`is the first process created in a GroupKit
`The Registrar
`Registrar.
`session. There is usually one Registrar for a community of conference users,
`and its address is “well known” in that other processes know how to reach
`it. This is the only centralized process required by GroupKit’s runtime
`infrastructure.
`When session manager processes are created, they connect to the Regis-
`trar. The Registrar maintains a list of all conferences and the users in each
`conference.
`It thus serves as an initial contact point to locate existing
`conference processes. The Registrar itself does not have a policy on how
`conferences are created or deleted, nor on how users join or leave confer-
`ences. Rather, it is the session manager which directs the Registrar to add
`
`ACM Transactions on Computsr-Human Interaction, Vol. 3, No. 1, March 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 011
`
`

`

`GroupKit, a Groupware Toolkit
`
`l
`
`77
`
`if requested,
`or delete conferences and users;
`these changes to other session managers.
`
`the Registrar then relays
`
`The session manager is a replicated process, one per
`Session Manager.
`participant,
`that lets people create, delete, monitor,
`join, or leave confer-
`ences. The session manager provides both a user interface and a policy
`dictating how conferences are created or deleted, how users are to enter
`and leave conferences, and how conference status is presented. We have
`already seen the Open Registration manager
`in Figure 1; other quite
`different managers
`can be created by the developer
`to suit different
`registration needs (see Section 6). Internally,
`session managers do not
`communicate with each other directly, but discover changes in conference
`state as information is propagated through the central
`list maintained by
`the Registrar.
`
`A conference application is a GroupKit pro-
`Applications.
`Conference
`gram and is invoked by the user through the session manager. This
`program, created by the application developer,
`is a groupware tool such as
`a shared editor, whiteboard, game, and so on. Conference applications
`typically work together as replicated processes,
`in that a copy of the
`program runs on each participant’s workstation.6 We call a process in-
`and the set of conference processes working
`stance a conference
`process,
`session. Different
`types of conference ses-
`together is called a conference
`sions may be running at the same time, all managed by the user’s one
`session manager.
`Although the applications do not have to worry about low-level details of
`session management, they may wish to be notified via an event when some
`high-level session change does occur. They may also retrieve information
`automatically
`by
`participants, which is maintained
`about
`conference
`GroupKit. This was shown in the “Hello World” example, where events
`tracked the arrival of a new user, and environments were used to retrieve
`both the local user’s and an arriving user’s name.
`Figure 6 illustrates these concepts. The centralized Registrar is running
`on its own workstation,
`and its address
`is known to this particular
`GroupKit community. Two users, George and Mary, have each invoked
`their own session managers, such as the Open Registrar shown in Figure 1,
`which communicate to the Registrar. Mary has used her session manager
`to create conference session A, which spawns the actual conference A
`process (e.g.,
`the GroupSketch program). To track session events, her
`session manager and conference process will maintain an internal commu-
`nication link to each other. George could then join that conference through
`
`execute
`usually
`session
`that make up a conference
`processes
`the conference
`6 Although
`is, the
`the same program,
`they can differ substantially
`as long as they are well behaved. That
`messages,
`data, and remote procedure
`calls
`sent between
`the differing
`programs must be
`understandable
`and must
`produce
`a correct
`response
`(the
`same
`is true
`for
`replicas
`of
`the session manager). As an example, Section 4.3 illustrates
`how two different
`versions of the
`“Hello World” program can coexist.
`
`ACM Transactions on Computer-Humsn Interaction, Vol. 3, No. 1, Msrch 1996.
`
`Meta Platforms, Inc.
`Exhibit 1018
`Page 012
`
`

`

`78
`
`l
`
`M. Roseman and S. Greenberg
`
`copy of the conference A
`a replicated
`his session manager, which creates
`process;
`a communication
`path betwee