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 22:39:41 --100
Message-id: <9404142036.AA12440@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: 7354
----- Begin Included Message -----
>From MAILER-DAEMON@dxmint.cern.ch Thu Apr 14 16:32:28 1994
Date: Thu, 14 Apr 1994 22:34:22 +0200
From: MAILER-DAEMON@dxmint.cern.ch (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: sg04%kesser@gte.com
----- Transcript of session follows -----
While talking to www1.cern.ch:
>>> RCPT To:<www-talk@www1.cern.ch>
<<< 550 <www-talk@www1.cern.ch>... User unknown
550 <www-talk@www1.cern.ch>... User unknown
----- Unsent message follows -----
Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4)
id AA16834; Thu, 14 Apr 1994 16:35:33 -0400
Received: from bucket by bunny.gte.com (5.61/GTEL2.19)
id AA23599; Thu, 14 Apr 94 16:30:55 -0400
Received: from kesser.cisl214 by bucket.cisl214 (4.1/SMI-4.1)
id AA18037; Thu, 14 Apr 94 16:32:12 EDT
Received: by kesser.cisl214 (4.1/SMI-4.1)
id AA12430; Thu, 14 Apr 94 16:34:36 EDT
Date: Thu, 14 Apr 94 16:34:36 EDT
From: sg04%kesser@gte.com (Yechezkal-Shimon Gutfreund)
Message-Id: <9404142034.AA12430@kesser.cisl214>
To: www-talk@www1.cern.ch
Subject: Re: Local program execution in WWW browsers
Reply-To: sgutfreund@gte.com
Bert Bos wrote me the following letter. I think it
illustrates some of the issues that I am raising.
] From: Bert Bos <bert@let.rug.nl>
] Subject: Re: Local program execution in WWW browsers
] To: sg04%kesser@gte.com
] Date: Thu, 14 Apr 1994 20:23:44 +0100 (METDST)
]
] It is good that you raised the issue again. Since you first proposed
] the Accessories, I've been thinking about them and drawing sketches of
] possible implementations. It is a complex matter, which might explain
] at least partially why there is little direct dicussion of your
] points. For a project that I'm working on I need something that is
] very closely related:
]
] a) controlling the graphic user interface:
]
] 1) I like to be able to use external programs to decode and display
] documents that the main browser cannot handle, but I like the
] output of the external viewer to appear *in the browser's
] window* even if the output is not HTML. This applies, e.g., to
] images in other formats than GIF, sounds, animations, editors,
] telnet-sessions.
]
This is much along the lines of Mark Litton's work on FRESCO.
See the X technical conference proceedings. (A Taste of FRESCO)
which should be part of the X11R6 release.
He has been working on this for several years, and has working
models.
Much of this model will also be part of the TK4.0 release.
] 2) Different documents need different interaction tools. E.g., when
] an MPEG movie is played, there should be a play/pause/stop
] control, when a sound is played, there should be volume control.
] These would be a extra buttons or a menu, that must also appear
] in the main browser window.
]
Yes, we are thinking along simliar lines here. I am looking forward to
the time of Mosaic being available in a ubiqutous computing environment.
That is, one can run it on a PDA. While the display metaphor might
be able to run intact on such a device, one might well have very
different sorts of interactors. That is, I might find the interactors
of the current FORMS mechanism very clumsy on a PDA. I might one
real physical sliders or controls on the PDA to map to the FORMS
input.
] 3) Like you proposed, some accessories should be available at all
] times, from an applications menu that is specified as a
] resource.
]
] b) controlling the functionality:
]
] 1) Some functions of the browser have to be disabled for certain
] documents (i.e., accessories): one cannot `save' a
] telnet-session or `view the source' of a sound.
]
] 2) Some other functions should be added when an external viewer is
] running, like the play/stop and volume controls.
]
] So far I haven't been able to come up with a single protocol that
] would allow all different external viewers to work. Some external
] programs are simple enough that they can be run as a filter,
] converting a document to a known format, such as HTML or GIF. Others
] need to interact with the user and will have to communicate with the
] main browser in a two-way protocol that should at least do the
] following:
]
] - add to the hotlist
] - remove from the hotlist
] - retrieve the hotlist
] - add to the global history
] - retrieve from the global history
] - change the displayed document without adding a new URL to the history
] - stop the accessory
] - disable some functions of the main browser
] - direct the browser to get a certain document
]
I have put the actual implementation of this work on hold until
FRESCO or TK4.0 comes out. At that time, I would see the creation
of a new WWW client as the desired methdology.
That is, all that would be left of the old Mosaic viewer would
be an HTML-viewer object. The window of this object would be mapped
into a larger composite tool. Interactor objects (pull-down lists,
VCR controls, etc) would map in and out of this compound display
on demand, depending on the document viewed. Different
sorts of interactors would map in depending on the terminal (Workstation,
notebook, PDA, beeper) that one was using.
I would like to see the FORMS interface completely broken out of HTML.
This was proposed in www-talk by Dan Conally, and he was really yelled
at about it.
But I liked it. That way the HTML viewer object would not be the dependent
on interactors at all.
Instead there would be a different HTML DID for forms. In some cases
a FORMS viewer object would be created and mapped to the display as
it is now. In other cases the Forms might be mapped directly to hardware.
E.g. physical sliders, virtual reality interfaces, etc.
Thus one would have a constellation of small acessorry applications.
each one implementing a particular task: HTML viewer, FORMS accessory,
etc.
Underlying all of this would be an orchestration agent. It would be a
non-visible piece of software.
Its main jobs would be to:
o fetch URI's
o coordinate shared resouces between accessories (incuding the HTML viewer)
- image cache
- etc.
o provide signaling functions to the accessories
o provide messaging services to the accessories
o other coordination functions
- e.g. tearing down accessories on exit
] And in my case I also need a way to have to have to X programs
] cooperate in a single window: one program would own the window, the
] other would own the parent and they should be resized together.
]
] Do you have specific ideas about possible protocols? You mentioned
] CORBA, but all I know about CORBA is that it is quite complex :-(
] The CGI-type interface may be alright for accessories that simply
] translate a document to HTML or to a URL reference, but it seems
] rather cumbersome for the interactive accessories.
]
] There is probably also a link with the client-side scripting language
] that Dave Raggett has been telling about, but I'm not sure exactly
] how.
]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yechezkal-Shimon Gutfreund sgutfreund@gte.com [MIME]
GTE Laboratories, Waltham MA ftp://ftp.gte.com/pub/circus/home/home.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
----- End Included Message -----
----- End Included Message -----