Distributed Systems Technology Centre
The University of Queensland, Queensland 4072,
Australia
Yarn is an existing electronic meeting system which had been ported to work with Mosaic. When linked to the World-Wide Web, the Yarn client and server processes combine to provide a service called Yarn Web, which appears as a separate window on the X display. Yarn Web features:
In its initial, central-server form, the Yarn system has proven to be a successful tool for group meetings of research personnel, and for open discussions on a range of topics of interest to people working together as reported in [3]. Although it is a straightforward text-based system requiring the users to type all comments, Yarn has proved very effective for the day-to-day communication of small amounts of valuable information such as file names, email addresses, appointment scheduling details, contact information, requests for action, short decisions, and so on.
Some of the next developments in the project are to investigate if this success will hold true when meetings are held between more loosely grouped colleagues, or between complete strangers who invited to join the electronic meetings. Because of the growing popularity of the World-Wide Web [14], it seemed sensible to investigate whether Mosaic could be exploited by the Yarn electronic meeting system to reach out to a wide range of users on a wide range of workstation platforms. When Yarn was converted to operate with the World-Wide Web it became known as Yarn Web. The outcomes of this investigation with Yarn Web are discussed in the remainder of the paper.
Based on previous experience with Yarn, five primary requirements were set for the design of the Yarn Web system:
At the outset of system design, it was obvious that requirements 1 and 3 could be easily met, since they mirrored features already present on the World-Wide Web and incorporated into the Mosaic browser. Taken requirement 5 into consideration, requirements 2 and 4 were to prove to be the main challenge.
To meet requirement 2, the server should update each participant's meeting conversation area whenever a user adds further remarks to the meeting. Only the server can detect when new remarks become available, but these events cannot be transmitted to the browser. This limitation makes real-time conversation within a World-Wide Web browser such as Mosaic almost impossible.
A solution was developed to circumvent this problem by taking advantage of the remote display feature limited to the X Window version of Mosaic. This led to Mosaic for X Window 2.4 being selected as the World-Wide Web browser for Yarn Web. In addition, this version of Mosaic offers full support for meeting participant input via Fill-Out Forms [ 7].
For the display of common documents, requirement 4, other solutions are also needed. This is because the HTTP server cannot initiate a request for the browser to load the document specified by a particular Universal Resource Locator [ 6] (URL). Two mechanisms were developed to work around this limitation. The first solution uses a static URL with dynamic content, while the second method uses the Remote Control [ 8] facility of Mosaic for X Window.
This facility allows any user with appropriate access permission to consult the logs of all past meetings, and the logs of all meetings in progress to the point at which the user elects to view the log. Of course, once the log has been retrieved from the World-Wide Web server, no further updates will take place until the user explicitly requests them by clicking on an `Update Log' button. However, this facility of consulting the log of a meeting in progress is a valuable new feature which was not present in the original Yarn system.
Figure 1: Opened Channels Connection Page
To join an existing meeting, a user first accesses the ` Opened Channels Connection' page from Mosaic as shown on Figure 1. Through the hypertext links at the top of the page a user can browse through the logs of meetings in progress. Having inspected the log, the user can proceed to join a channel. The connection procedure is illustrated in Figure 2.
Figure 2: Yarn Web Login Process
First the users fills in the local X server display IP address and selects a meeting channel as shown on Figure 3. When the user clicks the `Submit' button, the form contents are sent back to the HTTP server which passes the form contents on to the form query process called Yarn-query. Yarn-query responds to the request for connection and forks a new process to execute the Yxsimp X Window Yarn Web client on the Yarn Web server machine. To avoid overloading this machine, a limit of 20 is currently imposed on the number of simultaneous Yxsimp users.
Yxsimp sends a connection request to the Yarn Web server which connects the user to the meeting channel. The user then participates in the meeting using the Yxsimp window. A screen capture of Yxsimp is as show on Figure 3.
Figure 3: Screen Capture of the Yxsimp Application
Because of the relatively high bandwidth required for interacting with an X Windows application on a remote display, Yxsimp was designed to be a minimal version of a Yarn X Windows client. The goal was to create a fully functional client which uses a minimum number of Motif widgets.
------------------------------------------------------------------- Command Argument Description addurl URL Add a URL to the numbered list stored in meeting addurl n Delete a URL from the numbered list delallurl NONE Delete all numbered list of URLs stored in meeting doc NONE Display all numbered list of URLs stored in meeting doc n Load URL corresponding to n in the list on all client's machine with Mosaic doc URL Load specific URL on all client's machine with Mosaic --------------------------------------------------------------------Table 1: New Yarn Commands for Common Document Display
Each meeting channel maintains a list of URLs which can be loaded for common view during a meeting. A chairperson can use the addurl, delurl and delallurl commands to edit URLs in the list. The doc command is used for listing all URLs stored on the list or to load a document by specifying its URL or numeric order in the list. Two mechanisms were developed to display common documents. At first a static HTML file is created with a hypertext link to the designated URL. Users are notified of the loading of new document from Yarn Web by a message as follow:
LOG: Load Document - http://coral.it.Bond.edu.au:91776/reesm.htmlUser can then reload the static link page to find the hypertext link to the latest common display document. Although this solution works for all users, each reload of a document will require at least three mouse clicks:
An alternative solution was developed to eliminate the three clicks process. In this implementation, when a doc command is issued for the first time, the Yxsimp client will fork a new process and run Mosaic to display the designated URL on the client's workstation. The reloading of URL is done using the Remote Control feature in Mosaic for X Window. Yxsimp notifies Mosaic to load another URL by sending a SIGUSR1 signal, Mosaic then looks into the file /tmp/Mosaic.pid and find the new URL to be loaded. This process is illustrated on Figure 4.
Figure 4: Yarn Web Common Document Display Process
The only drawback of this system is for users that connect from the World-Wide Web Yarn Web login page, their Mosaic application is run on the same remote machine as the HTTP server. This has proven to be unresponsive for users on slow Internet links. Instead, Users are recommended to download Yxsimp client and run it from their local workstation.
When Yarn Web first became available, project members immediately switched to using it without difficulty, as all but one person was connected via X Window terminal windows. A few weeks' use was sufficient to verify the stability of Yarn Web.
The announcement of the availability of the Yarn Web system was posted to the Internet on 23 May 1994. Postings were made to four newsgroups, namely comp.groupware, comp.wais, comp.www and comp.gopher. From the HTTP log, the download request to connection ratio is around 2:1, ie more users will take a look at the information about the connection than will proceed to attempt a connection to the Yarn server. Such a low request to connection ratio is most likely due to the majority of users running a World-Wide Web browser on workstations without X Window display capability. It appears that the most frequent connections come from users running a Macintosh client. These users can still connect to Yarn but must use a Telnet connection method instead.
Another interesting phenomenon is the increase in HTTP traffic that the local server must field when such an announcement is made. Compared with the previous 96 days since the HTTP was installed, there was a 400% increase in HTTP server requests after Yarn Web was announced.
For the common document display feature in Yarn Web, the Mosaic by Remote Control implementation has proven to be a significantly better solution than the original method. The main reason is that the loading of URL is automatically handled by Yxsimp, while the original method required three mouse clicks to display a document.
Some of the users who have tried Yarn Web have sent in comments. A number have the intention of utilising Yarn for distance education purposes. Indeed, Yarn seems perfectly suited to the idea of a virtual classroom as discussed in [ 15]. Currently, Yarn is being used as a backup query line for courses teaching Unix and C and Object Oriented Programming.
The immediate development plan is to extend Yarn Web as a synchronous cooperation tool by adding the support of a shared whiteboard. Shared whiteboards provide a common drawing space for display of graphics details within a meeting context. Investigations are also under way for multimedia support of voice and eventually true video. Many other uses of the World-Wide Web could exploit such facilities and the arrival is confidently expected in the near future. Eventually the existing text-based interaction provided by Yarn will become the backup system used only in low-bandwidth situations.
Maintaining the original client-server model, the next revision of the Yarn server will be implemented with OSF DCE RPCs replacing the BSD sockets used in the previous versions. This architectural change in the server moves Yarn into a proper Open Distributed System model. Meeting servers will no longer run on fixed host machines. At run-time, Yarn clients will look up and connect to the available meeting servers by employing the DCE Cell Directory Services (CDS) thus removing Yarn's dependency on the existence of specific hosts and port numbers.
Provision of a common document display facility is a considerable addition to the original Yarn. It allows large quantities of textual and graphics information to be presented to all users during a meeting. Meeting participants can load up relevant information in HTML format and share this with others via Yarn Web. This method is particularly useful for sharing existing URLs between participants. Mosaic personal annotation also allow notes to be annotate into documents.
Obviously, the main intention of Mosaic is for one-way retrieval of information with limited interactions. The lack of two-way request support in the HTTP protocol has proven to be the major obstacle in the full platform-independent implementation of Yarn Web. Until major changes are made in the HTTP protocol to address this shortcoming it will not be possible to further integrate Yarn with Mosaic clients on a full range of native user interface platforms, other than using X server software on those platforms.
The work-around solution of using the X Window remote display capabilities works well for users within Australia. Due to the high bandwidth requirement for X, however, users connecting from other countries do not get satisfactory response on Yxsimp with heavy network traffic. This situation might be improved with the introduction of the Low Bandwidth X Protocol (LBX) in later releases of the X Window System [11].