W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: distinguishing browser types

From: Brian Gaines <gaines@fsd.cpsc.ucalgary.ca>
Date: Sat, 22 Apr 1995 15:49:33 -0600
Message-Id: <199504222149.PAA24343@fsd.cpsc.ucalgary.ca>
To: mwm@contessa.phone.net
Cc: www-talk@www10.w3.org
In message <19950422.74B9508.D72C@contessa.phone.net> Mike Meyer writes:
> It sounds like you want more than just content-type negotiation; or do
> you care what the helper does? I've seen a "helper" app that does
> nothing but save to disk (they didn't like the way the browser saved
> things to disk). So that I have a helper registered for
> application/postscript doesn't mean that I can do anything more than
> save it to disk.

I guess what hasn't been clear in what I've said is that it is MY helper
app that may, or may not, be at the client end. If it is there I can provide
more functionality. If not, I can still provide a viable service.

A good example is our concept mapping tool acting as a helper to Netscape.
It manages graphs of nodes and arcs and uses these to navigate hypermedia
structures. The tool can act as a helper but on Macs only currently. For
clients on other platforms it can act as a server sending the same material
in clickable maps.

Currently the URL determines what is done, but I'd prefer to do content
negotiation and just check the Accept field to see if the MIME type
supported by the helper is available.

WWW clients are becoming more and more open architecture so that the helpers
appear as seamless, functional part of the client to an end-user. It is
logical to pass info about helper MIME types in the Accept field.

For some background on what we are doing, see the report at:


sections 11 and 12 illustrate the issues above.


Brian Gaines              Knowledge Science Institute, University of Calgary
gaines@cpsc.ucalgary.ca   Calgary, Alberta, Canada T2N 1N4
                          tel: 403-220-5901  fax: 403-284-4707
Received on Saturday, 22 April 1995 17:56:11 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC