Re: distinguishing browser types

Brian Gaines (gaines@fsd.cpsc.ucalgary.ca)
Sat, 22 Apr 1995 18:01:43 +0500

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:

http://ksi.cpsc.ucalgary.ca/articles/ConceptMaps/

sections 11 and 12 illustrate the issues above.

b.

Brian Gaines Knowledge Science Institute, University of Calgary
gaines@cpsc.ucalgary.ca Calgary, Alberta, Canada T2N 1N4
http://ksi.cpsc.ucalgary.ca/KSI
tel: 403-220-5901 fax: 403-284-4707