Re: Local program execution in WWW browsers
sg04%kesser@gte.com (Yechezkal-Shimon Gutfreund)
Errors-To: listmaster@www0.cern.ch
Date: Thu, 14 Apr 1994 17:14:04 --100
Message-id: <9404141509.AA11705@kesser.cisl214>
Errors-To: listmaster@www0.cern.ch
Reply-To: sg04%kesser@gte.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: sg04%kesser@gte.com (Yechezkal-Shimon Gutfreund)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Local program execution in WWW browsers
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 15604
I proposed this a while ago, which covers a lot of the issues,
but did not see to much response.
Mosaic Accessories
External viewers
Currently, add-on functionality to the Mosaic viewer is accomplished
by means of external viewers. A viewer is a leaf process which is
invoked by Mosaic to accomplish a particular "add-on" function. Once
invoked the viewer operates autonomously, with no further connection
to Mosaic. The external viewer mechanism has proven to be a very
useful technique for extending Mosaic. In particular, for adding the
ability to view mpeg, jpeg, and audio files.
Problem statement
Although the external viewer mechanism is very powerful, there are
still are things that one cannot do:
News Browsers: A full function news browser needs to have
history file. The history file would then be used to prune the
article list (typically a UL list) to hide what one has already seen.
Additionally, one would like to be able to have kill files, search
functions, reply and post functions, etc.
Mail Tools: While browsing a mail archive, one would like to be
able to invoke standard mail tool functions. For example, after
selecting a mail message one should be able to reply, forward,
delete, file or print that article.
Form entry: HTML+ supports form entry. However, currently
all forms must be filled out manually. I frequently find myself
filling in standard info (name, e-mail address, mailing address,
etc.) Would it not be nice to be able to create "forms" that fetch
directly from files? This would certainly assist those who would
like to have forms where one entry item is a request for a 100KB
file.
Mosaic editors: The ideal Mosaic editor should work
symbionically with the Mosaic viewer. Allowing one to edit
HTML while simultaneously seeing it in the viewer.
Problem Analysis
Today, if one wants to extend the Mosaic client one has two choices.
1. External Viewers: However, a viewer, when invoked, operates
completely asynchronously with Mosaic. Furthermore, it
operates in complete isolation from what the Mosaic viewer is
doing.
2. Edit Mosaic: That is, modify the source code for Mosaic.
However, this is something that people shy away from doing.
Either because they don't know how, or given the pace of
releases from NCSA, they might be afraid of trying to keep their
edits current.
Outline of Proposal
I would like to suggest a simple modification of the viewer mechanism,
so that we could have a tool in-between the two above mentioned
extreme choices. That is, I am proposing something I call Accessories.
An Accessory can be thought of as a variant of an external viewer,
however it operates symbionically and simultaneously with the main
Mosaic client. Furthermore, there is a communication channel between
the accessory and Mosaic so that changes and updates can be sent
between the Mosaic client and its accessories (e.g. the HTML editor).
Examples of Current Accessories
Actually, Mosaic already implements the rudiments of an accessory
construct. For example, the Document Source Viewer, can be thought
of as a symbiotic accessory. Whenever the viewer changes location, so
does the Document Source Viewer. However, the source viewer is:
1. An integral piece of the Mosaic Viewer.
2. Does not have the necessary reverse communications channels
that a real HTML editor or Mail tool would need.
Other current (but even more rudimentary) examples of accessories
are: the Open Document Pop-Up, the HotList Viewer, and the
Binary-Save dialog box.
Related Work
The concept of an Accessory should also be familiar to people who
work with TK/TCL and to a lessor degree those who work with
Microsoft Windows Applets. In these systems one migrates small
constrained interactive functions to accessory applications. For
example, interactive drawing tools, chart tools, debuggers, paint tools,
etc. are implemented as Applets or TK tools that operate in tandem
with the main applications.
Maintaining a communication channel between application components
is an important part of both of these systems. With Applets, one uses
OLE to invoke and communicate information, while in TK/TCL one
uses the send mechanism (via the X11 property lists, or in TCL-DP via
TCP/IP).
This model of software, where compound applications are fabricated
out of a flock of inter-communicating sub-application tools, is also
becoming in vogue in the CORBA community.
Proposed Implementation
Feel free to write me with alternative suggestions. I view this
proposed implementation as very tentative.
Invocation of Accessories
Applications can be thought of as client side CGI scripts. Thus a
rudimentary way of implementing accessory invocation would be:
<A AREF=accessory.ext>Generic Accessory</A>
However, one would prefer not to specify an actual file, but rather a
MIME type which would then be mapped via the .mailcap file to the
accessory. This would allow one to create documents that specify a
generic type of accessory, and allow the user (via the .mailcap) to
choose the version of the accessory that he/she wishes:
<A AREF=accessory/x-html-editor>HTML Editor</A>
The .mailcap entry for this could be:
accessory/x-html-editor HTML-ED.exe
Sometimes one will want the user to manually invoke the accessory.
However, in other cases, for example a news reader, one would like to
have the accessories pop up automatically on certain pages. This could
be done by:
<A AREF=accessory/x-news-responder
MODE=immediate></A>
One would also like to place some accessories (e.g. the current
document viewer, mail-to, hotlist accessory, print, etc. ) on the Mosaic
menu bar. This could be done via x-resources (as is now done for the
old DOCUMENTS pull-down menu). Perhaps a better solution would
be to create an .appcap file whose entries would be used to create a
Applications pull-down menu for the Mosaic menu-bar. Entries in the
.appcap file would be of the form:
accessory/x-html-editor HTML Editor...
accessory/x-hotlist Hotlist Accessory...
Communications to/from Mosaic
Accessories are meant to operate in tandem with the Mosaic viewer.
Minimally, this means that accessories need to know what is currently
showing in the Mosaic viewer. They also need to be able to tell the
Mosaic viewer to switch to a new document. For example, the HTML
editor accessory receives the HTML document from Mosaic, and can
return the updated version of that document.
Communications with Mosaic is very similar to the CGI interface. That
is, there is a small header followed by a MIME type. For example:
Location: http://www.ncsa.uiuc.edu/index.html
Content-type: text/html
--- HTML DOCUMENT ---
where --- HTML DOCUMENT --- would be the HTML code for
the current document being displayed in the Mosaic viewer.
It is the job of the accessory to parse the HTML code. For most
accessories this will be trivial. For example, a news accessory just has
to parse a <UL> list of news articles - a very easy task. Most
CGI/WWW programmers are already pretty competent in PERL, TCL,
AWK, C-shell, or C, and there are fairly good tools in most of these
languages for scanning HTML and parsing it. I would expect these to
be the prime candidate languages for writing accessories.
CGI scripts, however, are meant to run once and return. This is not the
case with accessories. They should run in tandem with the Mosaic
viewer - and receive a new message-packet each time the Mosaic
viewer changes. Thus, we cannot use command line arguments or
environment variables. Instead communication occurs via standard
input and output. The actual format of a message-packet is therefore:
Location: http://www.ncsa.uiuc.edu/index.html
Length: xxxx
Content-type: text/html
--- HTML DOCUMENT ---
The accessory uses the Location argument to tell when the viewer has
switched to a new document. It can either update itself, or tear itself
down if it is no longer relevant. The Length argument tells the
accessory the length of the body (the HTML document).
The accessory communicates back to the Mosaic viewer in a similar
manner:
Location: http://www.ncsa.uiuc.edu/index.html
Length: xxxx
Content-type: text/html
--- HTML DOCUMENT ---
If the Length, Content-type, and body are left off, then the
message-packet is a standard remote-control directive - telling the
Mosaic viewer to GET to a new document. Otherwise, the Mosaic
viewer is to attempt to execute an HTTP PUT directive and replace the
HTML document.
Some accessories may not need the full HTML document, but instead
could get by with just a list of parameters. Other accessories might
want both start-up parameters and an HTML document. Parameters
could be passed in the body of the HTML document using SGML
comments. However, I believe the following is a cleaner way to handle
parameters:
<A AREF=accessory/x-mailer
ARGS="arg1=34&arg2=test"></A>
The accessory will then receive the following message-packet:
Location: http://www.ncsa.uiuc.edu/index.html
Length: xxxx
Arguments: arg1=34&arg2=test
Content-type: text/html
--- HTML DOCUMENT ---
where the arguments are URL-encoded.
External Communications
Accessories are free to talk to a variety of external ports. These could
include:
files, e.g. a news diary, a mail alias file, hotlist file.
external TCP-IP ports
infrared hand held remote device.
links to a pager.
Closed caption feed from a TV station.
links to a packet cellular or cellular phone (CPDP) link.
For example, one can create a two-way pager remote accessory (or
more likely a PDA such as the Apple Newton). Then one could in
effect, run Mosaic on one's pager, by having the accessory talk to the
pager. The accessory would be responsible for the translation of pager
events and request into Mosaic requests. Personal information (diaries
of news articles read, signatures, security codes, etc.) could be kept on
the PDA and accessed by the accessory to fill in forms or weed out
previously read news articles.
Another idea for PDA accessories would be a personal database
accessory. This database would contain information about what one
had already browsed on the net, personal filtering agents, information
about expense accounts, personal telephone directories, etc. Then, as
one moves from site to site and workstation to workstation, one could
plug this information into the local Mosaic Viewer in order to
personalize it.
In general this is the idea behind these client side accessories. That we
should be able to extend the Mosaic client to provide wider access to
Mosaic and to make it work in better harmony with other tools on our
hosts.
Communication Issues
The use of standard input/output for communications is less than
perfect. One problem is that it is a stream protocol. Which requires us to
either mark packet boundaries, or to give packet counts. Also, there is
no good channel for signaling events. However, packet protocols such
as TCP, UDP, or RPC are really not meant for such application
protocols. In the long run, I think we should be moving both the CGI
interface and the Accessory interface to one of the emerging
applications protocols. That is, either CORBA, OLE or perhaps a hybrid
multi-protocol interface. In any case, the final choice should be based
on it being widely used across platforms and suitable for both LAN and
WAN applications communications.
I have deliberately skirted the synchronization issue. That is, what
happens when there are multiple accessories all attempting to re-direct
the same Mosaic viewer. For the moment, I think we can allow such
race conditions to exist - since most accessories are meant to be
controlled by a single live user via their user interface. However, I
would like to hear the viewpoint of others.
Security Issues
Accessories are meant solve a security problem. One could implement
accessories today, with no changes in the Mosaic client, by means of
client code viewers. For example, a PERL viewer could be loaded with
arbitrary PERL code from a HTML document, and execute accessory
functions on demand. However, this would open up a door to trojan
horse code being uploaded to the client machine and running without
the users knowledge or awareness.
The Accessory mechanism gives the user the ability to:
Choose which accessories to use (those he trusts).
De-Virus and verify accessories before use.
Supply substitute secure accessories of his own creation.
Implementation Issues
Implementation of accessories seems to be a fairly straight forward and
simple modification of the current viewer mechanism. There is also the
issue of modifying the Anchor directive. However, it does not seem that
it would take a lot of work. I would certainly have gone ahead and
modified Mosaic myself. However, there are issues here that I think the
entire WWW community should be discussing. Furthermore, I would
want anything that is done to become part of the base-line Mosaic
system rather than just a personal variant Mosaic viewer.
Summary of Advantages
Allow OEM'ing of Mosaic GUI tools.
Currently tools such as the Document Viewer, Hotlist Viewer,
Mailer, and Document Saver are all integral parts of Mosaic.
NCSA staff has to be devoted to maintain these tools as well as
write new ones such as the HTML editor. The Accessory
mechanism will allow third party development of these tools.
Leading to wider customer choice and faster development time.
Stop Kvetching!
NCSA staff is frequently asked to make certain changes to the
Hotlist viewer, Mailing tool etc. By providing an easy customer
modifiable mechanism we can give the end user the ability to
create his own variants of these tools. Only basic PERL, AWK,
or C-shell script writing skills will be needed.
Consolidate functionality
The accessory mechanism consolidates current tools such as
the Document viewer, new tools such as the HTML editor, and
old mechanisms such as the Remote control feature, into one
unified simple mechanism.
Remote communications
There is an upcoming explosion of personal mobile physical
accessories. For example, two-way pagers and PDA's such as
the Apple Newton. The accessory mechanism is a quick way to
give a subset of Mosaic/WWW access to these devices.
Database access
Accessories allows one to have personal or external databases.
The accessory can then use these databases to provide
automatic form filling out, and filtering of mail or of news.
Security
Currently extending the client involves loading code into a code
viewer (e.g. a PERL or CSH viewer). There are big security
problems with this approach. The accessory mechanism gives
one a more secure means of extending a client.
Future Directions
Ultimately, one could imagine the Mosaic Viewer itself being
re-implemented as an accessory. Mosaic then would become an
background daemon process. This daemon process would act as a
master conductor, informing its accessories when a new document was
switched to, and arbitrating between the responses of the various
accessories. I believe this is the way that TkWWW now works. In such
a scheme we would have effectively OEM'ed the entire Mosaic
interface.
Document location
The HTML version of this document can be found on:
ftp://ftp.gte.com/pub/circus/accessories.html
Yechezkal-Shimon Gutfreund
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
+1-617-466-2933
sgutfreund@gte.com