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.
- Multiple views --
When a browser connects to the remote kit there can
be only one client kit with one server kit. It would
be nice to have multiple clients connect to one
server so there would be multiple views on one widget.
But that leads to problems with the semantics of
the eval() method. The eval() method returns
a string containing the result of the Tcl command.
But if the command was send to multiple client kits, the
server kit would receive multiple answers that may be
very different. This leads to messy semantics for the
result of Tcl commands. One solution can be to
restrict the eval() method so it does not return
a result. This would lead to a situation where the clients
can control the state of the remote widget but the
remote widget can not control the state of the client.
- Starting applications --
In our example the remote application has to be
started by the ``service provider'' since the remote
application runs under the uid of the remote user. It
is possible to compile a static message pattern into
the ToolTalk system so that ToolTalk automaticly
starts the application when there is a message for
it. But if some other user would request the same chat
demo page, the chat application will already be
running and the new client will use it as well. If
clients would act as multiple views, this would be an
acceptable situation but would not be if there must be
a one to one correspondence between clients and
servers. Clearly a mechanisme is needed to
distinguish between these situations. This problem
probably makes ToolTalk less suitable.
- Addressing a remote widget --
In our example the remote widgets is addressed via a X
server name and the widget name. But if there were
more identical remote applications running on that X
server it will be ambiguous which remote application
will be used. There is no mechanisme to address a
specific remote application. This is typically
something that is needed when there are multiple
viewers and multiple remote applications, for instance
when editting multiple music scores with several people
at the same time. ToolTalk offers possibilities to
send messages to specific processes identified by a
process identifier but it is only available when
the application has been started. A solution requires
that an application can be addressed uniquely whether
it is running or not.
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