| ||||||||||||||||||||||||||||||||||||||||||||||||||||
7th Tcl/Tk Conference, 2000
[Technical Program]
|
| Hemang Lavana | Franc Brglez |
|---|
![[*]](foot_motif.gif)
We propose a novel client/server architecture for tk-based applications: rendering any stand-alone client collaborative, without a code re-write. Participants themselves are allowed to dynamically re-configure the inter-client synchronization table to suit their changing preferences and needs. The CollabWiseTk toolkit, based on the proposed architecture, is an extension of the tk functionality to support collaboration. It re-defines the existing tk commands such that the entire tk widget set is rendered collaborative for use with multiple users.
We demonstrate the capabilities of the CollabWiseTk toolkit by readily rendering collaborative most of the Tk Widget Demonstrations, distributed with the core Tcl/Tk. The toolkit is implemented in pure tcl and it ports to all platforms.
Keywords: Internet, Collaboration, Groupware, Tcl/Tk, GUI.
A number of collaborative client/server architectures have been proposed to date. Principally, they deal with specific applications ranging from a shared calendar (The Electric Secretary) [3] to a shared whiteboard [4]; from collaborative visualization for health care [5] to collaborative editing of schematic diagrams [6]. An architecture that supports workflows of heterogeneous applications is described in [7,8,9]. Some architectures expect that the application has been written for a team of users, e.g. the GroupKit architecture [4]. Alternatively, multi-casting can render an application written for a single user collaborative, e.g. the REUBEN architecture [7,8,9]. There are disadvantages to both approaches: the need to write an application for multiple users, and the performance issues of multi-casting.
Most of the client applications today are as stand-alone applications. 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 [4,10,11].
In this paper, we propose a novel client/server architecture for tk-based applications: rendering any stand-alone client collaborative, without a code re-write. Participants themselves are allowed to dynamically re-configure the inter-client synchronization table to suit their changing preferences and needs. The CollabWiseTk toolkit, based on the proposed architecture, is an extension of the tk functionality to support collaboration.
The paper is organized into following sections:
Let us consider a very simple application which consists of a text widget with a vertical scrollbar. Such an application allows the user to type in text and the vertical scrollbar allows the user to browse the text information, when the size of the text widget is not large enough to display the entire text at the same time. This application can be very easily built using four lines of tcl code, as shown in Figure 1(a), and is a basic widget used by many complex applications that need functionalities such as syntax highlighted message display, text editing, and html display, to name a few.
Several possibilities exist even for a simple text widget that is rendered collaborative. Figures 1(b) - (e) shows various possible collaborative configurations of a text widget for two users Alice and Bob.
All of the above examples can be easily implemented in tcl by re-writing the four lines of stand-alone tcl code. However, when this text widget is part of a more complex application containing several other widgets, each of which can themselves have their own numerous configuration possibilities, it becomes very difficult to anticipate in advance a suitable configuration preference. Such a collaborative application might turn out to be user-unfriendly or confusing for a particular team.
The CollabWiseTk toolkit consists of two parts:
The general architecture of the toolkit is shown in Figure 2. This architecture extends and complements the Asynchronous Group Server Architecture (AGS) in [1].
SGS is a tcl server that accepts socket connections from various collaboration clients. It has three types of repositories:
The collaboration client is installed on each user's machine and provides an interface to the user for collaborating with other users. Upon invocation, the collaboration client establishes a socket connection with SGS and prompts the user to identify herself. Once the login process is completed, the user can access several different tcl applications, based on her access privileges, by invoking an appropriate configuration file from the inter-client synchronization table. Collaboration clients also maintain a local cache of the tcl applications for faster access.
The collaboration client also provides mechanisms to install new tcl scripts and packages in the group server repository. Privileged users can install such scripts and easily create configuration files on the server for others to access.
When two or more clients access the same configuration file of a tcl package, they are immediately set-up for collaboration. User-interactions with the tcl application are then sent to the group server, which in turn relays this information to all participating users.
 |
Inter-client synchronizer allows the user to dynamically re-configure the different modes of collaboration for every primitive object contained within the tcl application GUI. A primitive object is an element of GUI with which a user can either interact or observe: (1) all tk widgets, such as button, label, entry, etc, are primitive objects; and (2) in addition, tagged items of a canvas and text are also considered as primitive objects.
Primitive objects can be configured into either one of the two states - interact or observe. When a primary object is configured to be in observe state, a user is prevented from interacting with it. For example, a user can be prevented from interacting with a text widget by removing all of its binding tags, as follows:
![\begin{figure*}
\begin{center}
\indent
\includegraphics [width=5.3in]{Y_CollabWiseArch.eps}
\end{center}\end{figure*}](img2.gif)
bindtags .txt {""}
The same text widget can be brought back to an interact state merely by
restoring its binding tags.
A good introduction to bindtags can be found in
[3].
When several users work collaboratively, each user invokes the tcl application locally. Therefore, all primitive objects of an application are replicated on each user machine. In addition, a user can now configure her primitive object to be in one of the two states, interact and observe, and link it to any of the participating users. This means that when there are two users, say Alice and Bob, each can configure their text widget to be in one of the four states:
We next explain the meaning of each of this state for Alice:
The simple text widget example with a vertical scrollbar, shown in Figure 1(a), can be easily configured into various states by defining appropriate object state for the two widgets. Figure 3(a) shows a snapshot of a text widget GUI and Figure 3(b) shows its corresponding widget tree. This application is readily transformed, without any re-write, into: (1) collaborative shared editor for source codes (Figure 3c), and (2) a chat box window (Figure 3d), by providing an appropriate configuration file.
Figure 3(e) shows a snapshot of the inter-client synchronization table. It lists all the configuration files for the text widget in the left column, with their respective widget trees. Collaborative participants, if any, are listed in the adjacent columns. Thus, there are two participants for `Shared Editor' and `Chat Box', and only one participant for `Scrollable Text Box'. The entries listed below each user corresponds to the current state of the respective widget. For example, the text widget `.txt' under `Shared Editor' is listed as Interact/Alice for both the users, `alice@host.domain.com' as well as `bob@host.domain.com'. This implies that while Alice is interacting with her text widget, Bob also has the permission to simultaneously interact with Alice's text widget. The text widget is therefore shared among the two users thereby providing a means of real-time collaboration. Each such entry can be changed to a different state merely by clicking on the dropdown menus and selecting the desired state. We have used BWidget toolkit [12] to implement the GUI shown in Figure 3(e).
The examples shown above describe how each widget can be configured to suit one's requirements. However, as the size of the application grows, it can become very tedious for a user to configure each of this widget individually. Therefore we also provide a mechanism whereby if a user configures one widget to a specific state, then all of its subsequent children widgets also assume the same state. This becomes very useful when the user wants to start or stop interacting with the entire toplevel window and can be achieved by merely changing the toplevel window to the appropriate state.
The client-server architecture of the CollabWiseTk toolkit is implemented using socket programming. Typically several clients may be connected to SGS at any time. In addition, clients may invoke several tcl applications and each tcl application may have several different collaborative participants. Figure 4 depicts one such scenario, where user1 on client1 has invoked TkAppln1, TkAppln3 and TkAppln4, user2 on client2 has invoked TkAppln2 and TkAppln4 and user3 on client3 has invoked TkAppln1 and TkAppln2. An application that is common among users imply that those users are its collaborative participants. For example, TkAppln1 is rendered collaborative among user1 and user3. This is also shown as a dashed line linking TkAppln1 to client1 and client3 on the server side.
The following table provides such a relationship for the example shown in Figure 4:
| Application/Username | User1 | User2 | User3 |
| TkAppln1 | * | * | |
| TkAppln2 | * | * | |
| TkAppln3 | * | ||
| TkAppln4 | * | * |
As the number of participants and the number of applications increase, this could lead to very complicated relationships. Also, it is important that the server as well as the client maintain this information in a clean fashion without mixing up any information with one another. We, therefore, invoke a new interpreter for each client that connects to the server. In addition, a new interpreter is also created for every application that is invoked by all the clients. Similarly, the client also invokes a new interpretor for every application that the user invokes. These interpreters are invoked using the command interp create -safe - we make use of safe interpreters to provide adequate security among the client/server communication.
We next describe the mechanism used to capture events corresponding to user interactions and how these events are broadcast to its collaborative participants.
Interpreters on SGC are configured to provide a set of Tk commands such that in addition to being able to create, configure and delete generic widgets, these also include functionality to trap all the user interactions with the widget. Once the user interactions are trapped by the interpreter, it is upto sole discretion of the application-specific interpreter on how to process this information and it depends on the state of the inter-client synchronization table. For example, once the double-click on a button of TkAppln 1 by User 1 is captured, the interpreter does the following:
SGC interpreters also perform the functionality to receive and process events that are transmitted by collaborative participants.
Client-specific interpreters on SGS are configured to:
On the other hand, application-specific interpreters on SGS actually perform a inter-client synchronization table lookup to process an event and send it to all the clients that are in observe state.
Since users are allowed to choose to choose and configure the state of a widget in an application, it is very easy for widgets to fall out of synchronization with corresponding widgets of collaborating participants. For example, this occurs when Alice changes the state of her text widget from Interact/Alice to Observe/Bob. Before Alice can start observing the Bob's interactions with his text widget, Alice has to first synchronize her text widget with that of Bob.
The client interpreter of Alice sends a request to SGS to retrieve information necessary for her text widget to synchronize with that of Bob. The SGS server in turn transmits the request to Bob's client interpreter and waits for an answer. The Bob's client interpreter processes this request and responds accordingly by providing all the appropriate information about the current state of its text widget. Once, the two text widgets are synchronized, Alice goes into observe mode and starts following Bob's interactions.
SGS and the collaborative client communicate with one another using a well-defined set of APIs. There are basically two types of API commands:
When client1 sends a user interaction to a collaborative participant client2, it is not necessary for the client1 to verify whether client2 has managed to receive this information or not. Hence, this falls into asynchronous type of command.
On the other hand, when client1 requests specific information about client2, such as the status of its scrollbar, then it is necessary to issue a synchronous command. However, this implies that synchronous commands will block the socket channel between the client-server and prevent communication of other commands. Therefore, we always send asynchronous commands over the socket channel, and make use of the `vwait' command to implement the synchronous command.
Accordingly, we have developed two simple procedures to handle these two types of commands, as shown below:
![\begin{figure*}
\begin{center}
\indent
\includegraphics [width=6.0in]{Y_CollabWiseImplement.eps}
\end{center}\end{figure*}](img4.gif)
##
# 1. Asynchronous transmission
# sid = socket id
proc sendNforget {sid cmd} {
transmitSocket $sid {} $cmd
};# End of proc sendNforget
##
# 2. Synchronous transmission
proc sendNreceive {sid cmd} {
set returnId [clock clicks]
transmitSocket $sid $returnId $cmd
vwait $::returnId
};# End of proc sendNreceive
The procedure sendNforget, as the name suggests, sends the command across the socket channel and returns immediately. On the other hand, the procedure sendNreceive transmits a unique variable name, generated using the clock command and waits for this variable to be set using the vwait command. When this data is received on the other side, the presence of a variable name implies that a result is expected and therefore it transmits back the results such that this unique variable name is set to contain the results.
The notification of user interactions with a widget is achieved by analyzing the entire set of commands in tk widgets and re-defining these commands appropriately. Specifically, the original text widget is re-named and a new procedure is created by the same name. This new procedure performs actions that are necessary to:
The following tcl code snippet shows a simplified example of how a text widget can be made collaborative.
![\begin{figure*}
\begin{center}
\indent
\includegraphics [width=5.0in]{Y_CollabWiseLogin.ps}
\end{center}\end{figure*}](img5.gif)
## Rename text widget
#
rename text text-Org
proc text {pathname args} {
sendNforget $::sid "text $pathname $args"
set ret [uplevel 1 text-Org $pathname $args]
#rename $pathname cmd which just got created
rename $pathname $pathname-Org
proc $pathname {args} {
# process $args
switch -- $opt {
cget {
# send nothing to remote server, OR
# use "sendNreceive $pathname cget"
# cmd to get option value from rmt
# user, when configured for
# interaction with rmt user.
}
insert {
sendNforget $::sid \
"$pathname insert char"
}
};# End of switch stmt
# ....
};# End of proc $pathname
return $ret
};# End of proc text
Whenever the application invokes a text widget, the above procedure is called. It first informs SGS about the creation of the text widget using the non-blocking command sendNforget. It then proceeds with the creation of the actual text widget. Since creation of a text also creates a new command by its widget name called pathname, it re-defines pathname to pathname-org and creates a wrapper script for it. Other Tk widgets are implemented similarly.
We decided to use the Tk widget demonstrations, distributed with the core Tcl/Tk, as a test-bed for testing the CollabWiseTk toolkit. We have chosen these demos because they not only cover most of the commands in the tk widget set, but also demonstrate usefulness of the toolkit in rendering these applications collaborative. The experiments need to be conducted in two phases:
Our current implementation of the toolkit allows us to collaborate many of the listed demos. However, we have not yet implemented: (1) one major tk widget, namely the canvas widget; and (2) the tagged items on the text/canvas widget in our collaboration toolkit. Figure 5 shows the initial startup window of a collaborative client, which allows the user to connect and login to the synchronous group server. Figure 6 shows the main window of the tk widget demonstrations invoked in collaborative mode. Specifically, it shows a 15-puzzle game which has been made collaborative for two players as described next. First player can only click on the odd buttons whereas the second player can only click on the even buttons. Two kinds of games can be played with such a configuration: (1) players assists one another in completing the game at the earliest; or (2) one player tries to prevent the other player from completing the game.
We evaluate the CollabWiseTk toolkit in the context of several factors below.
User configurability. We provide the flexibility to save the mode of collaboration for a specific application in a static file. A programmer can thus anticipate a variety of useful collaboration modes and save it in separate configuration files. Users can then invoke the application with appropriate configuration file during collaborative sessions. However, users are not limited to using the collaborative mode defined in these files, but have the flexibility to also change the mode of collaboration, during run-time, to suit their specific needs.
System architecture. We have chosen a hybrid architecture to implement CollabWiseTk. A replica of the single-user application executes on every user's machine thereby providing good response times for local interactions. On the other hand, a centralized server is used for synchronization and maintaining consistent state information. This may result in performance bottlenecks where high interactivity is needed for increased number of participants.
Group awareness. Inter-client synchronization table maintains a list of active sessions corresponding to each application being shared. Additionally, every session not only lists the number of users actively collaborating on an application, but also displays the type of user activity such as interact or observe for a specific widget. This enables other users to determine the status of a particular user in respect to a specific widget and aids in increasing the group awareness significantly.
Floor control. The toolkit provides a very fine granularity over floor-control and allows the users to configure the interaction mode down to the widget element, instead of merely allowing control of the entire application. Additionally, users also have the capability to dynamically change and allow other users to interact with a specific widget of choice whenever the need arises. This provides better flexibility in letting users drive the mode of collaboration to suit their needs, rather than a programmer trying to anticipate all the collaborative needs for design specific collaborative-aware application.
Scalability. The scalability of the toolkit depends on the users and how they decide to share a specific session during runtime. If users want to be aware of all the activities of the other users, then there will naturally be a performance hit when the number of users increase. However, it is expected that most users will not work in such fully shared mode and would prefer sharing only part of the widgets from the entire application. This would minimize the communication overhead and hence this toolkit would offer good scalability even when the number of users increase.
Limitations. The architecture relies on a single centralized server to share the information for collaboration. This can result in disruption of collaboration services if the server fails for any reason.
Further details about the current status of these packages will be made available under:
https://www.cbl.ncsu.edu/software
We have demonstrated the capabilities of the CollabWiseTk toolkit by readily transforming most of the existing Tk Widget Demos into collaborative applications. Furthermore, the versatility of the toolkit is realized by the flexibility that it provides in rendering a stand-alone application into a variety of collaborative modes with little amount of work. Additionally, the functionality of these collaborative clients can be dynamically re-configured by the participants - thereby making it a very useful toolkit.
The re-configurability of the low-level primitives can be combined with one another to form several useful mega-widgets that better reflect users's models of work. This is illustrated with the help of a text widget and a vertical scrollbar, which is rendered collaborative as
Similarly, other primitive widgets can be combined to create numerous useful applications.
|
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=3.0in]{Y_CollabWiseTkWidgetDemos.ps}
\end{center}\end{figure}](img6.gif)