> So for example, the client could send a list of pre-defined formats to
> the server (e.g. IMG, TeX, PostScript, etc), and then the server can
> choose among different formats of the same item embedded in the
> document to give the client what it can handle. Sometimes, the server
> might not be able to convert the one of the things that the client
> (browser) can deal with, and then it's up to the browser to display an
> intelligent message about it, perhaps even giving the user information
> so he can find software for his desktop environment which DOES deal
> with that format.
...
The new version of HTTP (HTRQ/V1.0) does indeed specify how clients
can signal the server which formats they can support, although I don't
know of anyone using this facility as yet.
The use of separate viewers works but is somewhat clumsy right now.
I like the way that Windows on the PC supports runtime linking
with DLLs. This allows applications to load support for particular
formats only when it is needed, and to unload it afterwards.
A simple route forward for the Unix environment would be to write
stdin/stdout filters which output bitmaps (pixmaps). Maybe we can get
people to sign up to write some public domain filters for common
formats. Browsers could then accommodate new formats by mapping the
format name to the filter (with command line arguments for attributes).
The next choice is whether HTML should permit embedded data directly as part
of the document itself. A well defined escaping mechanism would permit
both ascii and binary data: e.g.
<embed type="text/eqn">X = sum from 1 to N of 1/Y^N</embed>
The simplest approach is to escape the "<" character, e.g. by inserting
a "\" character before any "<" character that occurs in the data (you
would also need to insert "\" before any occurrence of "\" itself).
Servers could still support format negotiation, sending different versions
of the document as appropriate.
What do you think?
Dave Raggett,
-----------------------------------------------------------------------------
Hewlett Packard Laboratories, +44 272 228046
Bristol, England [email protected]