re: Mosaic Accessories

sg04%[email protected]
Mon, 31 Jan 94 14:01:19 EST


There are a couple of design "principles" that (at least in my
opinion) seem important for the design of the ACI (accssory-client-interface):

1. It might be possible to "hack" an implementation out of
the current viewer & remote control structures (or modify TkWWW).
In fact I am already in the process of modifing TkWWW. Still,
what good is a local version done by one PhD working at a
telco research lab? It might be good for a paper at the next
multimedia conference (Indeed, I have just got one accepted at
the IEEE MultiMedia'93 Conference in Boston). But what good
does this do? I also had a paper at ACM Siggraph/MultiMedia'93,
and it didn't seem to do much. The multimedia world is not
really paying much attention to what gets done at the IEEE or ACM
conferences.

Mosaic, by dint of its rapid acceptence in the internet world, and
concurrent craze in public for exploring the internet, is becoming
a tremendous vehicle for shaping the "road-scape" of the information
highway. Thus, if we can get this feature imbeded into the
Mosaic software, we can have a significant impact on the nature
of that infomation highway.

2. The Accessory mechanism is meant to be more than just a way to
do symbionic editors. It is meant to combine multiple existing
tools (hotlists, document source viewers, etc.) and provide a
way for implementing a new class of tools, in addition to the
symbionic HTML editors

3. The current WWW model is largely (though not entirely) one
of fetch, then static display of document pages. Lots of
people have been looking for more interactive modes of interaction.
For example, game designers would like a more dynamic mode of
interaction. The accessory mechanism really opens this up.

One puts all one's dynamic interaction into the accessory. And
since it has a two-way pipe with the WWW client (e.g. Mosaic)
one can "piggy-back" on WWW. Things that correspond to static
documents can remain on the Mosaic side, while all dynamic
communications can remain on the accessory side.

Another example. I saw a while back a guy who wanted to link
live video captions to WWW documents. That is, lets have Mosaic
documents being cued by the TV feed. One thing my group has toyed
with is scanning the "hearing impared closed caption" info (you
can buy a box for this), and use it to key up documents. E.g.
one could have an accessory always running looking for hot
news stories. When one came through, one would fire off a WAIS
query, bundle up the results with the video clip and send it
off to the person who was interested. (Great product for
the Intelligence Analysts at the CIA who spend a lot of their
time scanning CNN :-) ).

4. Basically, what I am calling for is a "escape-hatch" were all
such dynamic modes of interaction could operated in tandem
with Mosaic. But it must be a standard. So that I can plug
into all sorts of other things on my machine (from Lotus Notes,
to Mac HyperCards, to DataBases, etc.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yechezkal-Shimon Gutfreund [email protected] [MIME]
GTE Laboratories, Waltham MA http://www.gte.com/circus/home/home.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=