re: Mosaic Accessories

sg04%kesser@gte.com
Date: Mon, 31 Jan 94 14:01:19 EST
From: sg04%kesser@gte.com
Message-id: <9401311901.AA24655@kesser.cisl214>
To: www-talk@www0.cern.ch, marca@eit.COM, timbl@www0.cern.ch
Subject: re: Mosaic Accessories
Cc: vinay@eit.COM, harawitz@fox.nstn.ns.ca, sg04@gte.com
Reply-To: sgutfreund@gte.com
Content-Length: 3377

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		 	   sgutfreund@gte.com [MIME]
GTE Laboratories, Waltham MA        http://www.gte.com/circus/home/home.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=