FYI: Here is how using content-type might work for your example of a
pseudo-newsreader (using a server of course).
<A HREF="http://server/rn.html">drink me</A>
on selection returns the document:
content-type: application/x-csh
... whatever you wanted rn.html to do
... links can look like <A HREF="http://server/article/####">read me</A>
http://server/article/#### returns:
content-type: application/x-csh
... whatever you wanted rn.html to do with the #### argument
So I argue we should figure out to have the browser talk to a local server
rather than figure out how to encode arbitary commands in the URL.
My reasoning:
o Browsers cannot change on a whim, because for the Web to be truly
useful to the user community at large all browsers must support the
**same** set of features (to a large extent anyway).
o Therefore we **must** have a definition for the browser that is simple
and complete such that any features you might ever want can be done
in a server.
So why the SAS that seems to be so prevalent? Instead of hacking
things into the browser we should be looking for ways to extend the
browser such that servers can do those tasks, but everyone seems to
be heading the opposite direction. Maybe this is something we
can take up at the workshop (what should go in the server and what
should we build-in to the browser).
I'm not a purist or anything, I think it's fine if we want the browser to
support things like gopher and ftp directly but at some point we are going
to have to draw the line if we want most browsers to support a common
set of features (even <IMG> is a good example of this problem).
--sanders