The Applet Version of I-P2

An applet version of the I-X Process Panel, I-P2, was developed as a
possible way to make it easier to start using I-X and to explore some
of the issues that arise in environments where security concerns
restrict the operations an agent can perform.  A further reason was
that a number of training applications would naturally use applets,
because related material could appear as web pages.

The main security restrictions on the applet are that it cannot
access files on the user's machine and that it cannot connect
to a port on any machine other than the one that provided the
applet.

In the current implementation, the applet appears as a new window,
rather than being part of the source page, and looks almost identical
to an ordinary I-P2.  Most of the usual functionality is available,
including an ability to exchange messages with other I-X applets
started from the same host.  However, it is not yet possible to load
or save plans or domains.

One goal of the communication mechanism was that it not require
any special configuration of the machine that provides the applets
(henceforth "the applet machine") beyond an ordinary HTTP server that
allows GCI programs to run.  In particular, it should not be necessary
to change the configuration of the HTTP server or to open any
additional ports to access from the outside world.  However, a
"message-server" would be running somewhere accessible from the
applet machine (it doesn't have to be on the applet machine),
and CGI programs would provide the interface with the rest of
the Internet.

There are two CGI programs.  One asks the message-server for a
description of its current status and formats that as text in
its reply to the CGI HTTP request.  This allows an applet user
to see what other applet users are on line and how recently
their applets were active, just by using a web browser
to look at the URL for this CGI program.

The other CGI program is used internally by the communication
mechanism to exchange messages with the message-server.  It
communicates with the server using an ordinary "simple" I-X
communication strategy.  To send a message, an applet makes
an HTTP requires to the URL for the CGI program, with the
message as the request's contents.  The CGI program then
forwards the message to the message-server.  The message-server
keeps this message until the intended recipient asks for it.
To receive a message, an applet sends a special "get-message"
message along the same route to the message-server.  The
message-server replies with the next message it has for that applet.
This reply follows the same route in reverse: from the message-server
to the CGI program, then to the applet.  (Note that each
HTTP request that an applet makes runs a new instance of
the CGI program, which tends to be inefficient.)

The key to making this work without an unreasonable amount of
user intervention is that an applet always has an active
"get-message" request.  As soon as it gets a message from
the message-server, it makes another request.  Since applets
may exit and restart, and since each message goes through
so many steps, it is not assumed that communication
is reliable.  The message-server keeps messages until the
recipient explicitly says that the message has been received;
and applets guard against receiving the same message twice.


Future work may include:

* Mechanisms for preserving applet contents -- the issues, activities,
  etc shown in the panel, plus any activity refinements the user
  defines -- so that the applet can be used in more interesting ways
  and over extended periods.

* "Pre-loaded" applets that have a suitable initial state for
  particular applications.  For example, an applet might contain
  the process that would be used to obtain and install a copy
  of I-X; or applets might be set up to allow plans to be found
  for particular problem domains such as the recovery of isolated
  personnel.

* A library of pre-defined plans and domains that can be used
  with applets.

* A simpler, easier to learn process panel GUI, such as Postix.

* A simplified, more efficient communication mechanism.  Instead
  of using the intermediate CGI program, applets would interact
  directly with the message-server.

* Use of a servlet container such as Jetty or Tomcat as
  infrastructure for the message-server.

* Support for communication with users who are not currently
  using their applet.

* Communication with I-X agents that are not applets and are
  not using the applet communication strategy.

* Applets for other types of I-X agents or for other I-X software
  such as I-DE.

* Signed applets that might be trusted to perform operations, such
  as reading and writing files on the user's machine, that are
  normally forbidden to applets.

