July 2009

"sharing single user application over distance"

Definition of SHARE

Many work environments require collaborative writing and editing of documents in diverse formats. In simple cases, there is essentially one author who receives approvals and comments from others. In other cases, the document is genuinely collaboratively authored using asynchronous or synchronous methods. A common way to collaboratively edit a document is to exchange draft versions between authors via email. This method introduces the possibility of conflicting changes and missed contributions as well as a significant burden as all members of the team are responsible for version control. The principle difficulty is that independent changes can be made to different versions, which must later be reconciled manually. It is also difficult to determine when and why a change was made.

This article introduces TellTable, an open source system designed to allow single-user software applications to be managed in a collaborative manner. We will discuss current collaboration models, the technical aspects of the TellTable software framework, security issues in its implementation, and tests of performance.

Collaboration Models

While collaborative writing and editing solutions have been offered since the 1970s, people prefer using single-user applications and distributing copies via email. Recently, designers have chosen to take advantage of the Web's popularity in the hopes of supplanting email's popularity. We see three writing and editing collaboration models offered on the Web:

  1. The upload/download model: a web server is used as a document repository. Group members upload and download documents to this repository, but edit on their personal computer, using a single-user application. One example of this approach is BSCWi, although that solution now offers online editing.

  2. The web native model: a special editor is built from scratch to work through a web browser. The resulting document is often in HTML format. There are numerous examples of this approach, including wikis, SynchroEdit, WriteBoard, NumSum, gOffice, and Google Docs and Spreadsheets.

  3. The hybrid model: a normally single-user application such as OpenOffice is adapted to work through a web browser. Examples of this include TellTable, coWord, coPowerPoint, and coStarOffice.

In the hybrid model, the use of a web browser to provide the display to the application allows users to employ a familiar interface to access document and application launching functions. It is feasible to use programs other than a web browser to display the data. Other non-web-based collaborative editing models include peer-to-peer and client-server models such as MoonEdit, SubEthaEdit, and Groove Networks.


With TellTable, underlying single-user software, such as OpenOffice, runs on a server. Users log into the server with a browser and view and interact with that software via a browser plug-in. This approach provides an easy migration path to users familiar with single-user applications while providing the benefit of a server that wraps the applications in a collaboration environment. This is consistent with our philosophy that the principle challenge with the design of collaborative systems is ease of use. Participants in a hard-to-use collaborative system will tend to resort to emailing private documents between each other.

TellTable was initiated in 2002 as an approach for spreadsheet auditing. By running the spreadsheet software on a server, all user interactions could be captured and centrally managed. Subsequently, TellTable was expanded into a framework for a general collaborative system. The server component of the project was licensed under the GNU Lesser General Public License in March 2004, and is distributed from Sourceforge. We are currently pursuing various enhancements to its functionality and are actively interested in collaborating with others on its further development.

For the user, TellTable functions like a web application. The user enters the server URL into an Internet browser and is presented with a login page. After entering a username and password combination, the user is presented with a screen showing the current status of all files to which they have access. At the lowest level of privilege, a user will be shown the file name, latest version number, and date/time and user name of the last file edit. If another user has chosen to "Edit" a file, it will be marked as "Locked", unless the user has chosen to share the session in which case it will be marked as "Shared". User privilege levels may be set to allow other functions such as "Audit" or to allow access to the version history of files. Figure 1 shows a view of the file access screen.

Figure 1: TellTable's File Access Screen


The "Download" option will cause the browser to download the selected file to the local machine so it can be manipulated locally. Those changes occur outside of the TellTable framework and cannot be re-inserted into the file version history without administrative privilege. The "Edit" and "View" options use a Java VNC viewer applet to connect to a VNC server running the appropriate software. The server implements the chosen function, interacts with user input, and updates screen output.

By default, a user editing a file has exclusive write access to the file which corresponds to an asynchronous workflow. In order to allow synchronous editing, a user editing a file must click "Share File". This will allow other users, with permissions to edit or view the file, the ability to simultaneously access the document. Since the underlying application is single-user, all TellTable users will see the same view of the document and will have their keyboard and mouse interactions combined to the application. This means there is only one cursor and people must take turns to enter data. While synchronous editing with shared input may appear to be a source of conflict, our experience is that such editing is normally done in conjunction with a conference call between participants. The group tends to nominate one user to make the changes, while others watch and comment. Our experience is that when users compete for control of the keyboard and mouse, the user experience may become chaotic but the software remains stable.

Because of the constraints of the Java applet security model, some operations function differently from their counterparts on a client workstation. First, the user needs to quit both the office software and the browser window. If the user closes only the browser window, the application is left running, and the user can access the application by logging back in. From a design standpoint, abandoned sessions need to be detected through a timeout and automatically closed. Second, copy-and-paste requires that we work around Java applet security that prevents applets from interacting directly with the clipboard of the client machine. Our design uses HTML input boxes to accept input from three sources of data: clipboard text, local files, and server files. In each case, the new data is copied to a read-only file on the server and opened as a sub-window of the OpenOffice document. This allows the user to select text from the uploaded document and paste it into the working document as required.

Open Source Components

A block diagram of the intercommunicating components of the server and a client computer is shown in Figure 2.

Figure 2: TellTable Design Components



TellTable is designed to offer cross platform support for Windows 98/2000/XP, Linux, and Mac OS X using Internet Explorer 5.0+, Mozilla 1.4+, Firefox, and Opera browsers. The client computer must have a graphical Internet browser with support for the HTTPS protocol and Java applets. The size of the VNC applet is configurable at install time with a default size of 900×550 pixels. This selection works well with screen resolutions of 1024×768 or higher, but can be a little inconvenient for lower screen resolution settings.

The core of the TellTable server is a pool of VNC server processes which may be distributed across several physical servers. At system boot time, a custom Perl program performs an initialization of the TellTable environment and initializes a TellTable server to accept and process commands.

The TellTable server runs under Apache on Linux. The web server components are primarily CGI scripts written in Perl. SSL encryption is used to protect login information. TellTable maintains a database of system activity using the BerkeleyDB format. Locking of the database between multiple CGI script invocations is implemented using the Perl module DB_File::Lock.

File versions are stored using the concurrent versions system (CVS) which allows branching, merging, and file differencing. TellTable's simple sequential progression of version numbers uses CVS to allow extraction of older versions and to maintain descriptive text logs with each version. Because TellTable manages conflicts using locking, CVS capabilities for branching and merging are not required. Although file differencing would be of great benefit to users, CVS was designed for plain text files while multimedia and other office software files are typically binary. This means that the "diff" functions of CVS do not work as expected. A useful presentation of document differences would need to be determined at the application level, and some office software provide this function, but we are not working on interfacing to this capability at the moment.

Security Design

Collaborative work introduces security concerns that do not exist for the individual author. We categorize these as server vulnerabilities, client computer vulnerabilities, access control, and access level control.

Server vulnerabilities: collaborative systems require a networked server which, as a minimum, maintains a repository of file versions. Such network servers are potentially vulnerable to cracking through the applications running on the server. In more complex applications, the server is required to perform more complex operations, exposing it to a larger pool of possible attacks.

Client vulnerabilities: collaborative editing is not without risk to a client computer, even when exchanging draft versions via email. Most sophisticated office suites support macro languages, which are a popular vehicle for computer virus transmission. Since TellTable runs such applications on the server, it is important to protect it against viruses.

Access control: collaborative endeavours typically have a well defined group of participants. To ensure legitimate access, most systems require a login with a username and password. There are well known problems with password based systems which is a significant concern in a web-based system.

Access level control: group members often have different access privileges. Errors in setting access levels, especially in a complex system, can give users unwarranted additional privileges.

The TellTable server has a firewall configured such that only the HTTPS and VNC protocol ports can be accessed from the Internet and client machines. The firewall completely blocks outgoing network access from TellTable servers, meaning users and attackers will not have access to the server software running on the TellTable servers.

At server initialization, each TellTable process has a unique random code string embedded into it and stored in the Web server database. When issuing a command, the TellTable server calculates a SHA1 message authentication code based on the command text and the stored code. Commands with an invalid authentication code are ignored with an error. This code also serves as a one-time password for connections to the VNC server. This mechanism ensures that the user of a previous VNC session cannot eavesdrop on a future session since the authentication information will no longer be valid.

Perhaps the most vulnerable aspect of TellTable is the concern that users may be able to run arbitrary software as the userid used by the TellTable servers. This exposes the following vulnerabilities: i) users may snoop on other TellTable users; ii) users may attempt to hack the server; or iii) software may access the Internet to attack other machines or to act as a proxy or mail relay. In order to defend against such activities, TellTable has implemented three layers of defence. First, we attempt to prevent such access by careful configuration of the single-user software running on TellTable. For example, the options to browse the file system and run macros are disabled. Second, to prevent arbitrary file system access, each process is run within a UNIX chroot which serves to isolate each process and the executable programs it is allowed to run from the rest of the TellTable file system. This helps prevent snooping of the TellTable server and other TellTable users. Third, the firewall is configured to block all outgoing Internet activity and only permit incoming activity on the VNC and HTTPS ports. This helps prevent use of TellTable for malicious Internet activity.

When the CVS repository is on the same computer as the Web server, file versions are stored under the userid of the Web server. If the CVS repository is on a separate machine, CVS commands are transported via SSH encryption. SSH authentication credentials are stored using the ssh-agent mechanism at Web server startup so the authentication information is not available to the Web server.


TellTable has been used by several workers at the University of Ottawa, the Communications Research Centre of Canada, the University of Vienna, and two independent teams linking Ottawa and Cardiff and Ottawa and Toronto. Applications include collaborative authoring of scientific presentations and articles, multimedia course material, and maintenance of course marks and documentation.

In the autumn of 2003, we performed our first pilot study of TellTable to manage spreadsheet files used to record course marks. Results showed that users appreciatived the features of the system, especially the ability to know one's changes would not be lost. Overall, usability was good. One concern was that responsiveness would suffer on slow Internet connections with high latency. We were pleasantly surprised to find that even over slow links, TellTable was quite usable.

Some software bugs were triggered by patterns of usage of pilot users. For example, Hotmail opens links within a frameset that uses javascript to rewrite HTML to prevent breaking out of the Hotmail frame. Generally, the Hotmail rewriting would incorrectly rewrite the VNC applet frame, rendering it non-functional. The solution was to require logging into TellTable from a new browser window. This example also highlights the concern that such a technique could be used to capture passwords and other security information.

In terms of scalability, our tests indicate that the server memory requirements are relatively small compared to that required by the operating system and the spreadsheet data itself. Performance was calculated by performing simultaneous complex spreadsheet calculations. Results show that the TellTable server evenly distributes available computational resources with very little overhead. These results suggest that a moderately sized server with 1GB of memory should be able to support 10−20 TellTable sessions, depending on the requirements of the users. Since most uses of Office applications make sporadic use of computational power, it may be more efficient to use a powerful server for TellTable with less powerful client computers than individual powerful client machines.


TellTable runs on a Linux server and supports clients using most popular operating systems and Internet browsers. We believe that the TellTable server is portable to other UNIX platforms, although we have no plans to do so. A port of the server to Microsoft Windows would require a significant rewriting, as Windows does not easily allow multiple graphical sessions to run under different userids, as is required by TellTable. However, it is possible, using CodeWeavers Crossover Office, to run Microsoft Office software on Linux. In preliminary tests, we were able to run Microsoft Powerpoint remotely with TellTable. However, it is unclear whether such use is permitted by the software license.

We have considered using a faster framework for dynamic web content than CGI, such as mod_perl. However, our current tests show that for reasonable loads of up to ten simultaneous users, the speed of the web server does not significantly degrade. Most delays in the web server are spent interacting with other system tools, such as the CVS or VNC servers. A possible annoyance with our design is the detection of real changes in files. For example, in Microsoft Word, opening a document, scrolling through and saving it, may result in a modified file. A version control system such as TellTable, will save these versions, unless software were written to detect such unchanged files. For the moment we have chosen to wait and see if this is problematic.

Initially, we considered dynamically creating a new VNC session when requested by the user. This approach proved infeasible because VNC servers require about 5 seconds to start, resulting in additional delay for the user. Worse, when the VNC server shuts down, its TCP/IP connection is left in the TIME_WAIT state and cannot be restarted for up to two minutes. An approach based on dynamically started VNC sessions would need to work around such timing considerations. Also, initiating VNC sessions for other userids requires elevated privilege for the web server, which may introduce security issues.

Another possible design approach considered was to maintain a VNC session for each system user, making security analysis easier. Unfortunately, this approach would require a large memory and processor capability to support a large number of users. Further, since each VNC server requires its own TCP port, it would require many open ports. As currently implemented, a VNC server is limited to 99 open sessions (TCP ports 5901-5999). Load balancing with multiple servers is another difficulty. If all logged on users happened to be allocated to the same VNC server computer, other machines would not be able to assist in supporting the computational load.

Our future technical work with TellTable involves improved usability and security enhancements, while simplifying some of the processes. One goal is to expand the set of applications we can launch and use with the infrastructure. We are also exploring ways to integrate workflow capabilities into the file-choice screen, since automation of the flow of files and information should enhance the utility of the infrastructure. As an open source project, TellTale benefits from the availability of ideas and code but requires input of time and resources from those choosing to join the project.

In conclusion, TellTable is a workable framework allowing single-user applications to be used collaboratively. This framework is open source and runs on inexpensive hardware. The TellTable approach benefits from considerable effort put into the development of user-friendly features in large software packages. Its value is in making it relatively easy to make such software function in a collaborative way. Pilot results show that users are generally able to use their familiarity with such software packages to work easily and effectively with TellTable.

This article is based upon TellTable: An Open Source Collaborative Editing System which is available for download. The original article provides more in-depth coverage of TellTable's technical design.

Recommended Resources

Knowing What was Done: Uses of a Spreadsheet Log File

Evaluating and Implementing a Collaborative Office Document System

Computer-Supported Collaborative Writing


Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!