Chatting on the Web

Postscript, W4G paper, W4G
Martijn van Welie and Anton Eliëns
Vrije Universiteit, Department of Mathematics and Computer Science,
De Boelelaan 1081, 1081 HV Amsterdam, The Netherlands
email: {martijn,eliens}@cs.vu.nl, fax: +31.20.4447653
www.cs.vu.nl/~{martijn,eliens}/

abstract

This paper describes the concept of remote applications that can be used in conjunction with a web browser. By using other communication protocols on top of http, remote Tcl widgets can be used in Tcl scripts that can be contained as applet in a web document. An experimental demo in Hush is described in detail, followed by a discussion of the concept.

Introduction

The Web is slowly becoming more and more alive. The days ofthe static pages are counted for and with the introduction of inline applets, the web is becoming increasingly more dynamic. In we described an extension for Hush, a webwidget, that among other things lets you execute Tcl code inside a HTML page. This way simple applets like those written in Java  [ Gosling95], could be done in Tcl. In combination with other Hush extensions like a MPEG player and a Tcl interface to Csound (the Hymne extension) even more interesting applets could be written. You can make your HTML documents as dynamic as you want. By now it has become clear that the execution of scripts like Tcl, Python or Perl, or languages like Java, are a powerful means of building more dynamic features in Web pages.

Joining a session

With our work we try to stretch those boundaries even further. In order to reduce the size of the browser but not compromising the offered functionality and to create even more interesting new functionality in web pages, we are developing a browser that interacts with remote applications. This way a user can interact with programs by requesting a certain page on the web. We developed an example which lets you join a "chat" session, like the well known IRC chat programs, simply by requesting a HTML page. Like with Java, the page contains an applet and the applet is executed within the browser. Only in our case we execute Tcl code instead Java code. By extending the application tag in the HTML page with information about the remote application's location, the browser knows how to make a connection with the remote application. This illustrates the use of new functionality that the browser nor the WWW server itself do not support. The browser only has knowledge of the meaning of certain tags that indicate interaction with a remote application. Figure relations shows how the components in this scheme relate to each other.

Related work

Basicly this is also offered by Java applets but it is done in different way which boils down to sending the complete source of an applet. In contrast to our solution, the Java code is merely a piece of text with a specfic meaning and no actual communication between the browser and the application exists. We think that this is not always desired or necessary as is demonstrated with our example. For serious applications, ``publishing''; the source code may be a very big objection. Maybe that is why most Java applets (as the name applet implicitly states) are merely ``funny little applications''. However if we were able to ``publish'' the interface of a application and still have if work, applets could offer far more interesting functionality.

HushTalk, communication on top of http

For the actual communication between the browser and the remote application we developed and new Hush extension called HushTalk. It is based on Sun's ToolTalk which is a message based system for inter-application communication that is promising in becoming a standard. It is available for Unix platforms as part of the standard Solaris 2.x distribution and is being ported to other platforms. With HushTalk we tried to handle communication in a more Hush kind of style i.e. by calling handlers with events that contain messages instead of installing C type of callbacks. Our example chat program uses HushTalk to actually set up the required communication and so does our browser to communicate with the chat program. So we are using HushTalk as an other communication protocol on top of the http protocol.

Creating new widgets

One of the features of Hush is that new widgets can be created. These can be used on both a Tcl and a C++ level. The chat application of our example HTML page is also a new widget. This way the possibilities of Tcl can be extended to suit the needs. So the Tcl script that is contained in the chat page consists of only two lines : 

  chat .c
  pack .c
Since chat is no standard Tcl widget, not every interpreter will know a chat widget unless it has been installed. The interpreter we use our browser does not have a chat widget either. It would not be wise to link every interesting widget with the browser, leading to a large monolithic browser. We employ an other solution. When an applet tag is encountered, the value of the class attribute is interpreted as the name of a new widget and a dummy widget is installed in the interpreter. This way, any widget can be used in a HTML page. The widget actually becomes a remote widget since the real widget implementation may reside elsewhere. In the next section will be explained how remote widgets work as if they were locally installed.

Realisation in Hush

To realize the remote execution of applications we developed new kit classes to do the work. In Hush the concept of a kit is the abstraction for the graphical toolkit that is used by a Hush application. The kit class provides access to the underlying toolkit that is used and manages the associating between script commands and C++ code. In the Tcl kit we use, the {\tt eval()} method is used to execute Tcl scripts and the {\tt bind()} method is used to associate a handler object with a Tcl command. This way a flexible two way mechanisme between a toolkit and C++ code is realised. Figure twoway illustrates the relations between the toolkit and Hush C++ code.
If applications have to function as a remote application the interpreter that is associated with the remote application should not be it's own interpreter but an interpreter on the client side. So it involves separation of the interpreter and the Hush application but have it function like it normally does. We created new kit classes for the client and server side which together accomplish this objective. For the execution of Tcl code the server kit does not execute it but sends it to the client kit in a request for execution. In response the client kit executes it in it's interpreter and sends back the results. This simple mechanisme takes care of the script execution and the remote application does not notice any difference. The commands with associated handlers require more work. Tcl code that is received by the client may contain commands that are known in the remote interpreter and not in the client interpreter. So when a new command is created in the remote kit, the client kit is informed and also creates this command, so a one to one correspondence exist between commands. When during execution the command is called, the client kit delegates it to the remote kit ; the remote kit is the only one who knows which handler is to be called. The remote kit executes the command in it's interpreter and the standard Hush mechanisme's will call the appropriate handler. So to have it work for commands requires that both client and server have an interpreter. Now the interpreter and the application have been separated in the sense that actually an other interpreter than it's local one is used. By designing new kits for the client (in this case the web browser) and the server (the chat program), any application that uses such a kit can be used in a client-server fashion with a web browser. Since every Hush program needs a kit, all that is needed is to recompile your program with a server kit.

Communication protocol

A client kit receives all the interface code, in our case Tcl code, of the remote application it is connected with. In order to effectuate user interaction, the client kit also feeds back the user events to the server kit which in turn notifies the server application. The result is that we actually have pealed off the interface of an application and distibuted it to a client in such a way that the user doesn't notice any difference, except for some performance loss.

Security

Security is an important topic in web applications. Our protocol is neither safe nor unsafe. When a programmer writes an application he controls what is sent to client kits and what is received from a client kit. The same holds for the client application (the browser) except for the results that are sent back to the server. It is possible to execute Tcl code that has confidential client data such as the contents of files on the filesystem of the client, as a result. So it's is important that the client interpreter is safe in respect to it enviroment. In our implentation we use a safe Tcl interpreter most file IO is disabled. However, if either the client or server decides to put sensitive data such as credit card numbers in messages (e.g because of a {\tt eval()} command) that are sent, that data will be readable for any message receiver. Perhaps the contents of messages should to be encrypted before it is sent since ToolTalk does not offer ``safe'' messages. So no new security holes are introduced but the ``old'' existing ones about safe interpreters and safe message passing still remain a problem.

Some considerations

Although our example shows that remote widgets are possible, there are some points of considerations. These points need to be addressed for future development of the concept. Solutions for the above points are not plausible. It seems that ToolTalk may not be suitable for the task by lack of needed features. A possibility that needs to be looked in, is how the functionality of a WWW server would have to be extended to forfill the role ToolTalk now has. As maintainer of the HTML documents is has control over the contents and in particular the embedded applet tags. It could also easily start applications on the same host.

Conclusions

Applets can make web documents much more interesting, either for decoration of HTML pages or to offer new functionality such as games or other little applications. By using Tcl code that can contain remote widgets, a whole new range of applications can be used as applets. Since the applications are available as single widgets, large and complex widgets can be used. Our solution removes the interface of an application, like removing the front of your car radio, and still have it working properly in a web page. Although an experimental setup has been realized, taking the concept further requires more research into the requirements of running remote applicationsnin conjunction with the web.
Eliens95b
A. Eliëns, Hush -- a C++ API for Tcl/Tk, The X Resource, Issue 14, April 1995, pp. 111-155
ToolTalk
Astrid M. Julienne, Brian Holtz, ToolTalk & Open Protocols ; Inter-Application Communication, SunSoft Press/Prentice Hall, 1994, ISBN 0-13-031055-7
Doorn95
M. van Doorn and A. Eliëns, Integrating WWW and Applications, Proc. of the 3th Int. World Wide Web Conf. -- Technology, Tools and Applications, Computer Networks and ISDN systems, Vol 27. No 6, Elsevier, 1995, pp. 1105-1110 www.cs.vu.nl/~dejavu/papers/Darmstadt95/
Ossenbruggen95
J.R. van Ossenbruggen and A. Eliëns, Bringing Music to the Web, Proc. of the 4th Int. World Wide Web Conference '95 -- The Web revolution, World Wide Web Journal, O'Reilly and Assoc., Inc., pp. 309-314 www.cs.vu.nl/~dejavu/www-95/ \bibitem{java} James Gosling, Henry McGilton\\ {\em The Java Language Environment: A White Paper}\\ Sun Microsystems 1995\\ {\tt java.sun.com/whitePaper/java-whitepaper-1.html}
Gosling95
J. Gosling and H. McGilton, The Java(tm) Language Environment: A White Paper Sun Microsystems, available at http://java.sun.com/whitePaper/java-whitepaper-1.html