[about fine tuned content negotiation for images]
> In general, though, I think this kind of fine-tune negotiation should
> occur as *close* to the client as possible - so that if three people
> behind the Hensa proxy cache want different bitdepths of the same image,
> hensa can download the canonical version of the image and downconvert
> accordingly if it wants, rather than store three different versions.
The trade off between proxy filestore and image quality has been discussed
before on this list. Those folks who see images as trivial decoration
tend to prefer proxies playing fast and loose with image conversion, while
those who treat graphics as important content tend to prefer image
conversion done in a more controlled environment on the originating server.
To use an analogy, bar.html could be converted by a proxy to bar.txt, and
then, later, bar.txt might be converted to bar.html again (add <pre> and
</pre>) but the result would loose something in the process.
There is also the issue of which of a selection of image formats is the
canonical one, and how to expire foo.8bit..palette.png and foo.gif once
foo.64bit.best.png changes. In other words, even if proxy conversion was ok,
how do we express the dependencies?
Content-type: image/png
Makefile: http://foo/bar/Makefile
;-)
-- Chris Lilley, Technical Author +-------------------------------------------------------------------+ | Manchester and North HPC Training & Education Centre | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | URI: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html | +-------------------------------------------------------------------+ | "The first W in WWW will not wait." Fran?is Yergeau | +-------------------------------------------------------------------+