| ||||||||||||||||||||||||||||||||||||||||||||||||||||
7th Tcl/Tk Conference, 2000
[Technical Program]
|
| Franc Brglez | Hemang Lavana |
|---|
| Zhi Fu | Debabrata Ghosh | Lorie I. Moffitt | ||
|---|---|---|---|---|
| Steve Nelson | J. Marshall Smith | Jun Zhou |
![[*]](foot_motif.gif)
Keywords:
client-server architectures, collaborative computing, Internet,
Tcl/Tk, GUI.
There is no consensus about the definition of collaborative computing. It appears that while Computer-Supported Cooperative Work (CSCW since 1960's) may have been eclipsed by groupware, the notion of collaborative computing is still being molded. Checking out a web-based search engine with keywords such as 'CSCW' returns about 44,470 links to related Web pages, 'groupware' returns about 228,940 links (mostly about Lotus Notes, NetWare, Office97, ...), while 'collaborative computing' returns only 8,857 links, several already listed under earlier keywords.
This paper is one of the two companion papers
[1]
that were initiated at the conclusion of the course on
Frontiers of Collaborative Computing on the Internet
(csc591-b, [2]).
This course defines
'collaborative computing' as the hardware, software and structures that
support a group of individuals working on related tasks - where hardware,
software, data, and individuals may be distributed over a wide
geographical area. 'Groupware' is a subset
of collaborative computing: it is the software that allows communication,
coordination and the sharing of information between distributed individuals and
groups. Common examples of groupware are e-mail and video conferencing
facilities, shared access to databases of documents and images, and applications
such as shared white boards. A number of commercial systems are available to
support such activities and the systems continue to evolve
[3].
The main goal of csc591-b is to introduce collaborative computing as
a distributed process, asynchronous and synchronous, that invokes,
links, and executes
To make this process less abstract, we introduced the notion of a collaborative
project:
A project driver that matches this definition, and is within the scope of a single semester graduate class, is the creation of a distributed environment that supports collaborative document composition. The class instructor acts as a project leader and document editor, while students, having created a distributed environment first, maintain bibliographical databases, create graphics for embedded illustrations, write and compile the pre-assigned sections of the document. Most of such activity uses clients that interact with the local host of each participant, while periodic synchronization and sharing of data with other participants takes places when each client links to the common server.
While the environment as described above appears specific to document
composition, the implementation, conceived as part of the class project,
demonstrates a universal client/server architecture where the same server can
now support any number of user-configurable, project-specific tasks or workflows.
In order to complete most of the key objectives of the project before the end of
the semester, we made Tcl/Tk [4]
the scripting language of choice
at the very beginning. The first few weeks of the course were devoted exclusively
to the introduction and exercises in Tcl/Tk.
Our choice of Tcl/Tk for the class project in collaborative computing was
also influenced by a number of favorable experiences with Tcl/Tk, each of which
could also be shared and critiqued in the class environment, such as
GroupKit [5],
AgentTcl [6],
user-configurable workflows [7],
recording and playback toolkit [8], and
toolkit for the web-browsers [9].
This paper introduces the Asynchronous Group Server Architecture
(AGS) and a platform-independent client
as it was conceived and implemented for a number of collaborative demos
as part of the project in this course.
The paper is organized
into several sections as follows:
Hands-on case studies, in class and as homework,
of various client-server architectures covered
The Electric Secretary in [10],
GroupKit5.1 in [5],
REUBEN in [7].
In addition, the class was introduced to
WebWiseTclTk in [9],
which assisted in migrating the client application to the Web.
Some of the homework assignments were completed and submitted as
recorded sessions, using
RecordnPlay in [8].
The introduction of AgentTcl in [6]
was dropped due to lack of time.
A number of collaborative client/server architectures
are known. Principally, they deal with single
applications rather than workflows of applications, ranging
from a shared calendar
(The Electric Secretary) [10]
to a shared whiteboard [5]; from collaborative
visualization for health care [13] to
collaborative editing of schematic diagrams [14].
This class project builds on the
recent experiences with collaborative
workflows of heterogeneous applications
[7,8,15]
and the client-server architecture of
The Electric Secretary in [10].
The latter served
as the initial model for the
Asynchronous Group Server Architecture (AGS)
described in sections that
follow.
The example that motivated and guided much of the class discussion and one that became the project driver, is first shown as an informal arrangement in Figure 1. The project involves the project leader (instructor) and a number of students. The objective of the project is to write a joint paper on the technology that will have enabled the class to devise and implement a client/server architecture to compile the paper in a collaborative mode. In the arrangement as shown in Figure 1, we assume
The compilation process itself may consist of all or some of the following steps:
This arrangement, while workable in principle, has a number of drawbacks:
We next introduce an abstraction that formalizes the project description in
Figure 1 such that we can also render it collaborative.
Formalizing the views.
The document composition project illustrated in Figure 1 can
be executed using a makefile - but only if data and tools reside on
the same host. In general, this is not the case. The sequence of executable
tasks in Figure 1 defines a simple workflow that can be
represented with an acyclic Petri net graph consisting of data and tool nodes,
with tool nodes acting as transitions that execute (or 'fire') only when all
required input data is present at the inputs of the nodes. This is a special
case of the more general case that involves graphs with cycles
[7].
The graph representation, with distributed data nodes invoking tool nodes
on any number of distributed file servers, is an effective GUI for the workflow
client applications. In particular, such representation can readily support
collaborative features and user-configurability. Three views of the essential
features of such a client interface are outlined in Figure
2:
set-up view, asynchronous view, and synchronizing view.
Without loss of generality, we continue using the document composition
project illustrated in Figure 1 as the illustrative example.
To keep the presentation simple, the project leader (Fred) engages only two
participants: Alice and Bob. The expected output from this project is a
multi-section document on a specific topic, with Alice and Bob contributing
technical sections, and Fred acting as the editor and also contributing the cover
section, the abstract section, and the maintenance of the bibliography database.
Set-up View.
Shown in Figure 2(a), this is a view of the client as
initially configured by the project leader (Fred). In this project, task completion
implies sequential execution of one or more tools from the set
{makeClean, latex, bibtex, dvi2ps, ps2pdf}.
With the exception of makeClean, these tools read instances of input files
and write instances of output files. The task of the tool makeClean is to
delete all of the intermediate file classes such as
{*.aux, *.bbl, *.dvi, *.ps, *.pdf } since any file instances in these
classes can be regenerated by invoking the tasks that are driven by instances from
primary input file classes such as {*.tex, *.bib }. Generating and
editing instances of files in these two classes represents the essential
contribution to the project from each member of the team.
In the set-up view, Fred has the exclusive r/w ownership of all files in the class
*.bib as well as the files 'main_fred.tex', 'title.tex' and 'abstract.tex'
in the in the class *.tex. The files 'section1.tex', 'section2.tex', and
'section3.tex' are shown as owned by 'server', indicating that other team members
are free to claim ownership to any of them.
The file 'main_fred.tex' has a listing of any *.tex and *.bib files that are
to be included in the compiled document. With the
exception of ps2pdf, shown as controlled exclusively by Fred, there are no
restrictions on execution of other tools. At this point, Fred can execute and test
the task execution of the entire workflow by invoking makeClean and then
latex on 'main_fred.tex', to be followed by other tool invocations until
reaching ps2pdf. Alternatively, any segment of the tools could be chained
for automated execution of the entire task sequence or any subsequence.
At this stage, the files 'section1.tex', 'section2.tex', and
'section3.tex' are simple template files with tentative titles and are yet to be
expanded and edited by Alice and Bob.
Asynchronous View.
Shown in Figure 2(b), this view of the client depicts
the work in progress, with contributions from Fred, Alice and Bob. Specifically,
Alice claims ownership of 'section1.tex', and 'section3.tex', while Bob claims
ownership of 'section2.tex'. In addition, each has created files 'main_alice.tex'
and 'main_bob.tex', respectively, to execute any desired combination of the
files from *.tex and *.bib class. In this view, the three
participants work to a large extent independently, while each can always access,
read, and process the files created by others. Typically, each may be editing the
files on a local host rather than the server where all files are accessible to
all the tools in the flow.
Synchronizing View.
Shown in Figure 2(c), this view depicts the
state of the client when the project leader Fred has scheduled a project review and
a collaborative editing session in which all team members participate.
While the team may reside at different locations, all communicate with each
other, at the minimum via a chat-like window on the terminal screen.
In the best
case scenario, participants may communicate also via audio and/or a video channels.
The main goals of the review are (1) to synchronize versions of input files
generated by distributed team, (2) to review and edit individual files, and (3) to
share the control of the flow execution for the final version of the document. This
is an interactive and collaborative process in real time.
In the synchronizing view as shown in Figure 2(c), most
files are returned to the ownership of the server - allowing any team member to
access them in r/w mode for editing. In particular, we note that Bob has secured
access to 'abstract.tex' - a file originally generated by Fred. The decision
to access this file by Bob has been made after a brief discussion among all team
members. In its crudest form, the mechanism by which others can observe Bob's
editing is to download the revised file on prompts from Bob. In a more elaborate
environment, others may observe Bob's editing in real time on their own terminal
screen. Ultimately, one may expect an environment where two or more members may be
editing the same file in real time in a user-friendly and an unambiguous manner.
Issues in rendering a client collaborative.
Given the code for the stand-alone client application, the
traditional approach is to re-write it as a client for collaborative
application. This can be a formidable task, especially when all possible
preferences for modes of collaboration cannot be anticipated in advance.
Such a client may turn out to be user-unfriendly or confusing for a particular
team. Simple preferences, such as whether and when should the scrollbars track
for all participating collaborators, or should separate scrollbars be provided
(and color-coded) for each participant, are at the core of such issues
[5,17,18].
Such issues are addressed, and an effective solution proposed,
in the companion paper
[1].
Generic examples of issues in rendering a stand-alone client collaborative,
as introduced and discussed in the class setting,
are included in the lecture notes
[2]
and the companion technical report
[19].
The project driver example as introduced in Figure 1,
and more formally in Figure 2, has been instrumental in
arriving at the two-way partition of the server architecture to support
two dynamic views of a collaborative project:
Due to limited time, the emphasis of the course was to prototype a client/server architecture that primarily supports the asynchronous view of collaboration and is described in the remainder of this paper. However, the simple demos, by the end of the class, that demonstrated the feasibility and the potential of the synchronizing view of collaboration, have also provided the direction beyond the class setting, leading to the companion paper on the SGS client/server architecture and implementation [1].
We have defined the concept of a collaborative project and the notion of a partitioning a set of project-specific tasks and data among project participants - giving rise to one or more workflow clients that are to be executed by participants in asynchronous and synchronizing modes. In addition, we identified behavioral classification of objects in the workflow client partitions, impacting the way we propose to implement a collaborative client. All of these factors have influenced the current view of the universal user-configurable workflow client interface and the corresponding server architecture.
We first specify the GUI of the client, and describe how it relates to the
proposed client/server architecture. This specification
served as a blueprint for
the student teams implementing several versions of both the server (in Tcl) and
the client (in Tcl/Tk), as
described in the subsequent sections.
GUI for the Client.
The currently proposed and implemented workflow client interface consists of
five major 'frames', each with a number of functions:
.
The bindings for the tools may be hard-wired in the initial versions of the
client, but will be loaded later from a user defined configuration file,
identified with a specific flowID.
Client/Server Architecture.
The proposed client/server architecture in Figure 4 matches
the concept of a collaborative project as stated earlier: a number of workflows
configured and partitioned by the project leader may be associated with
each project; whereas participants may work in an asynchronous
mode on the project partitions as well as a synchronizing mode. This concept
is reflected in the client/server architecture which itself is partitioned into an
Asynchronous Group Server (AGS) and a Synchronous Group Server (SGS).
For each project and workflow invoked by the participant, the AGS maintains not
only the project data archives and workflow libraries but also an Objects
Ownership Table preconfigured by the project leader. Once invoked,
the Objects Ownership Table initializes the Inter-client Synchronization
Table which interacts with SGS and the participants' clients.
A brief description of anticipated user-interactions in the
interactive collaborative mode (where the Inter-client Synchronization Table can
be changed dynamically by the project participants) is given in Figure
4. See the companion paper
[1] for more details.
Project status by the end of semester.
One student has implemented a version of the AGS
server that supports all features as defined for the client in Figure
3 - except the file subdirectories for individual participants.
A total of five similar but different clients have been independently developed
by collaborating pairs of students. The toolFrame in one of these clients
is user-configurable, so the client is truly universal.
In the document composition project, each participant can maintain/release
ownership of files. A simple naming convention allows each member to execute the
project partition independently of others, while the project leader can assemble
and edit the complete document for immediate access and feedback to all. The
client is invoked through a Web browser from any platform (UNIX, WindowsNT,
MacOS) and collaborative execution can take place with distributed participants.
The paper concludes with highlights of AGS design, client design, and
collaborative experiments conducted with the universal client/server architecture
for three different applications: distributed document composition,
distributed software debugging and compilation, and distributed experimental
design environment.
The design of a collaborative server was very critical to the success of this class project. There are several requirements of the server. It should support and maintain:
The first step was to define and develop a communication API (application
programmer's interface) that can be used by the client/server to meet
design requirements, as outlined above.
We decided to employ asynchronous communication scheme, as
described in [10].
The server was configured to understand a minimal set of commands.
The mechanism for client/server communication is described next.
The client sends a request to the server which consists of a string
of the following form:
server_cmd arg1 arg2 ... argn client_cmd
The server processes the request from the client by invoking
a procedure server_cmd, in a safe-interpreter, with n arguments.
After the server_cmd completes its execution, the server parses
the client_cmd string and replaces all occurrences of
(1) "%v" with the result returned by
server_cmd execution, and
(2) "%l" with the length of the result returned by
server_cmd execution.
The new client_cmd string is then sent back to the client, which
processes the string received in a safe-interpreter.
However, whenever execution of sever_cmd results in an error, the
server sends error_result reason to the client, instead of sending
back the client_cmd string.
The list of commands recognized by the server falls
into four categories:
login <user> <pswd> <project> <client_cmd>
If the user logs in successfully, then the following commands
are made available to the client.
checkOwnership <filename> <client_cmd>
grabOwnership <filename> <client_cmd>
releaseOwnership <filename> <client_cmd>
A client can assume ownership of a data file, only if it is owned
by the server. On releasing the ownership of a data file, the
server becomes its owner.
All three commands return the current ownership of the file.
getList <client_cmd>
downloadFile <file> <client_cmd>
uploadFile <file> <data> <client_cmd>
deleteFile <file> <client_cmd>
executeCommand <what args> <client_cmd>
This single command gives the server the flexibility to invoke
any tool specified in what args without having to restart the
server when a new tool need to be added to the services.
However, it can also be major concern for security.
We resolve this issue as described next.
Configuration Makefile.
The server is designed to maintain several projects.
Each project is restricted to access a limited set of tools only,
depending on what tools are required by the project.
A configuration makefile, stored in the project directory,
determines the set of tools available for any given project.
Each tool needs to be explicitly specified in the makefile
along with the command line arguments necessary for its invocation.
A typical entry in the makefile, which generates a pdf file from
a postscript document, is as shown below:
document=A00_main
ps2pdf:
ps2pdf $(document).ps $(document).pdf
This task may be invoked from the command line as
make ps2pdf or make ps2pdf document=A00_Brglez.
In the first case, the default value (A00_main) of the document
is used, whereas in the second case, the document rootname is specified
on the command line.
Thus, a client would typically send the following command to the
server to invoke the above task:
executeCommand "ps2pdf document=A00_Brglez" "puts {%v}"
The server will invoke this task, if available, in the project directory.
As the course evolved, so did the versions of the client implementations and likewise, the versions of the server implementations - a true learning experience for everyone in the class. Unlike the server design which was completed by a single student who had prior experience with TclTk, the client design was completed by students who only learned TclTk during this course. While sharing the debugging experiences with each other, a total of five clients were designed independently by five student teams.
Each of the clients implemented the basic functionality as specified in
in Figure 3 and the screenshot of each client,
demonstrated and tested for collaborative
document composition functionality
during the last session of the class, is archived as part of
the report posted on the class home page [2].
Each of the clients was tested through a Netscape
browser and was executable from a UNIX, MacOS, and WindowsNT workstation,
provided the browser has installed the WebWiseTcl
[9],
Safe-Tcl plugin, and the csc591b (course)
policy. The latter is required to download and save
the files from the server to the local
client.
Each team was also responsible to contribute a subsection highlighting elements of TclTk used to achieve the required functionality. A representative GUI for the client is shown in Figure 5. Like all other clients designed in this course, this client is executable from window in a web-browser. This particular client is universal: the contents of the toolFrame are loaded from a user-specified configuration file, which is linked to the project-specific makefile maintained by the server. In addition, this client makes use of the B-widget Toolkit [20] to implement its GUI.
We use the the initial client interface specification in Figure 3 to briefly describe the GUI of the client in Figure 5.
loginFrame.
The loginFrame is invoked by clicking on 'Network Information'
in Figure 5.
A set of entry boxes will prompt the user to enter 'UserId', 'UserPw',
'ProjectId', 'FlowId', etc. A set of well-placed buttons will allow user
to 'connect', 'login', 'disconnect', 'loadFlow', 'removeFlow', and 'exit'.
toolFrame and reconfigurability.
The toolFrame can be 'hard-wired' as part of the flow-specific client
itself (e.g. the composition project flow), or can be loaded as a
user-specified configuration file that is linked to the
flow-specific makefile on the server. This configuration file can
only contain a subset of the targets and dependencies of the makefile.
The toolFrame of the
client shown in Figure 5 has been generated
automatically by loading the configuration file.
The flow shown chains the applications that are used in the document
composition project and can invoke 'Clean' to remove old work files,
'LaTex' to generate a compiled version of the document, 'BibTeX' to
create citation indices, 'LaTeX Again' to load to update the document
with citation indices, 'Dvi2ps' to create a postscript file, and
'Ps2pdf' to create a document in the pdf format. In the example shown,
links between 'LaTex', 'BibTeX', 'LaTeX Again' have been
activated by the user (shown now as arrows after each click
on the connector bar), so all
buttons are executed consecutively once the user clicks on 'LaTeX'.
Such control of execution, from task i to task j, cannot be
achieved with the make utility, where only the end-task j
can be specified by the user.
The entry for 'file rootname' allows each user to select the name
of the 'main.tex' file that should be invoked upon execution of the
flow.
Additional examples of the universal client invocation, for different
sets of tasks, are shown in Figure 6.
filesFrame.
The filesFrame has three parts:
two listboxes that list files on the server and the client in the
directories specified by the project name;
a set of control buttons to allow a number of transactions take
place between the two listboxes: file 'upload', 'download', 'release
ownership', 'lock ownership', 'refresh', etc.
These transactions take place once the filename has been highlighted
in a specific listbox. By clicking on the file name, the contents of
the file are displayed in the text window.
The display of the files in the listboxes can be filtered by clicking
the appropriate class selection, e.g. *.bib would display files in
this class only.
In addition to files, the listboxes also show the current owner of the
file. Only the file owner can modify or delete a file. There are two
ways the owner can release ownership of a file: (1) by clicking on the
file in the ownership field, or
(2) by highlighting the file name and clicking the 'release' button.
In either case the ownership field will change from 'userId' to
'server'.
There are two
ways the owner can lock ownership of a file when it is owned by 'server':
(1) by clicking on the file in the ownership field
(it will change from current server to
'userId'), or (2) by highlighting the file name and clicking the 'lock' button.
In either case the ownership field will change from 'server' to
'userId'.
editFrame.
This frame is invoked by clicking on 'Text File Viewer/Editor'.
The editFrame includes a scrollable text widget in which user can write,
modify, or delete text of a file that has been retrieved from the
directory on the server or the client - depending on user selection.
Besides the text widget, additional widgets in this frame provide
functionality such as 'edit file', 'save on server', 'save', and 'clear'.
stdoutFrame.
The stdoutFrame is a scrollable text widget which accepts inputs from
standard output and standard error. Its main purpose is to maintain a
log of all transactions taking place between the server and the client.
A number of experimental testing of the client/server architecture was taking place for most of the last third of the course. During the last week of the course, there were two sets of student presentations and demos: as a dry run and as a brief presentation/demo during the open house. These demos came in two sets:
Demo set 1. The complete set of demos that used the universal client described in Figure 5 is summarized in Figure 6:
Demo set 2. This demo set consists of the remaining four client implementations devised by student teams. Except for the universal user-reconfiguration of the task flow implemented in Figure 5, all of the client GUI designs have implemented the collaborative task flow for document composition in LaTeX as per original specification in the class. The minor difference in the interface are a reflection of individual preferences and the interpretation of the design specification. The screenshots of these client GUI designs are available in a technical report [19].
Notably, all
implementations of the client have tested as executable through a
web-browser. The latter included the implementation of the
csc591b policy that allowed each
participant to download and save files in the directory
of the local host - thus
overriding the nominal defaults of the web-browser. Currently, such
fine-grained security policies
are not as readily achievable with browser-based clients
written in Java.
Final impressions. As the course concluded, there were really no surprises. The client/server architecture behaved as expected - it allowed multiple students to independently complete the writing assignments about a phase of the project which would then be shared with other participants and included in the overall document such an early draft of this paper. Preliminary experiments, such as rendering a single-user application collaborative under user-controlled preference also took place - a promising new approach, now described in more detail in the companion paper [1].
The material for this paper evolved as part of an experimental course on 'collaborative computing'. We are no closer to making a definite statement about what actually is the most appropriate definition of 'collaborative computing' than we were in the first paragraph of the paper.
In the context of this project, definitions are less important
as the expectations we may have of collaborative computing.
Bringing together a class of students and learning
a scripting language that allows for rapid prototyping
of user interfaces and networking concepts, and linking it all to
a well-defined project driver, has been an important motivating
factor for each participant eager
to improve the environment where collaboration can be
a rewarding learning experience.
The rewarding
experience has been not only to learn the textbook material but
also to question existing client/server architecture and
to try some new ones.
The projects on the
Asynchronous Group Server Architecture
and the Synchronizing Group Server Architecture
(SGS) along with the respective clients continues as a
small project and both the server and the client software is expected
to be
released for use by the peer community during the year 2000.
See
https://www.cbl.ncsu.edu/software/
for more details.
|
This paper was originally published in the
Proceedings of the Special Workshop on Intelligence at the Network Edge,
March 20, 2000, San Francisco, California, USA
Last changed: 11 Feb 2002 ml |
|
![\begin{figure*}
\begin{center}
\indent
\includegraphics [width=6.3in]{Y_projInformal.eps}
\end{center}\end{figure*}](img3.gif)
![\begin{figure*}
\begin{center}
\indent
\includegraphics [width=6.25in]{Y_projPartition.eps}
\end{center}\end{figure*}](img4.gif)
![\begin{figure*}
\begin{center}
\indent
\includegraphics [width=5.3in]{Y_SGS-A...
...ce only as
$o/\ast$\space or $-$.
\end{tabular} }}
\end{center}\end{figure*}](img7.gif)
![\begin{figure*}
\begin{center}
\indent
\includegraphics [width=6.5in]{Y_clientDesign-demo.ps}
\end{center}\end{figure*}](img8.gif)
![\begin{figure*}
\begin{center}
\indent
{\bf (a) Configuration to execute a col...
...th=5.5in]{Y_clientConfiguration3.ps}
\vspace*{0.1in} \end{center}\end{figure*}](img9.gif)