Mosaic Accessories
sg04%kesser@gte.com
From: sg04%kesser@gte.com
Date: Wed, 26 Jan 94 13:45:32 EST
Message-id: <9401261845.AA17618@kesser.cisl214>
To: www-talk@www0.cern.ch
Subject: Mosaic Accessories
Reply-To: sgutfreund@gte.com
Content-Length: 16322
[I believe I sent this to the wrong address the first time]
I have been giving the thought of www-client extension mechanism a good
deal of thought (especially how to access information from pagers,
PDA's, PPP notebooks etc). I have sent this document out to several WWW
heavies, and gotton some responses.
I don't have the chutzpah to think that one person can grasp all
aspects of this problem, so I am opening this up to the entire WWW
community. I would like to collaborate with design and implementation
with those who feel that this general approach is of merit.
The original HTML document can be read from:
ftp://ftp.gte.com/pub/circus/accessories.html
-------------------------------------------------------------------------
Mosaic (WWW client) 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
----- End Included Message -----
----- End Included Message -----