Re: Accept- & Content-Resolution headers proposal

On Thu, 7 Jun 2007 20:21:08 +0100, Nicholas Shanks
<contact@nickshanks.com> wrote:

> > The DPI switching should be done in CSS.
> 
> which is great until CSS is not available.  The point of this is to  
> provide such switching where it's not already available.

No matter what, the client is going to have to support something -- be
it this, or (more appropriately) a higher-layer method for determining
which resource to pick.

> This header would be most important when no CSS is involved (e.g.  
> directly accessing a resource outside of HTML/CSS context, or  
> selecting a css file in the first place, though this could be done  
> with a css switcher file that loads the appropriate sub-resource).

I think that, while things other than HTML can be transferred over
HTTP, they're somewhat out of scope. It is, after all, the HyperText
Transfer Protocol -- though a command extension, as you have suggested,
could certainly be used to create a HyperImage Transfer Protocol.

> One of the things i didn't make clear was that this would only apply  
> to images and/or files that reference images (and i suppose only  
> those that don't have inherent DPI selection for such references,  
> e.g. XSL)

I'm glad you cleared that up -- because it was exactly the point I
was driving at. :)

The server should not have to discriminate "images" and (even worse)
"image-referencing-files" and make the DPI selector work for only those.
If the selector doesn't have at least the potential to make sense for
all files (or, at a bare minimum, HTML files), then should it really
be in the transport?

> Reviewing the feedback so far, it looks like this use case
> (switching DPI) is too narrow to bother changing the spec for as CSS
> can fill 95% of the use cases, but that there *is* a need for
> preferring smaller files even if they are of lower quality. I suggest
> thought be focused on that.

Q-values (as mentioned elsewhere) already do exactly that -- albeit
with limited control, but with the benefit of taking only one trip.
Having a way to see all the varies (also mentioned elsewhere) would
probably more generally useful, but will require up to three trips.

If we're going the latter route, the problem can be solved above the
transport level, by writing up an RFC for, e.g., "automatic location of
multiple resource representations using RDF." Have a scheme similar to
the robots.txt or favicon.ico -- files with multiple representations can
be detected by appending .multi (or whatever). Given that the .multi
file is present, process it and make your choice. Existing servers
can support it, lots of clients already have all the technology they
need to implement it, and it'll play nice with proxies and caches (!).

The worst-case scenario would be getting a full 404 hit, which could be
mitigated by doing a HEAD before a full GET (under the assumption that
_most_ files will not use this mechanism). This would require two
or three round trips for most media-esque files -- HEAD->404->GET the
original file, or HEAD->200->GET the .multi->200->GET the chosen file.
There might even be some fancy-dancy conditional GET you could use to
reduce it to one trip -- but I haven't read the spec in a while, so no
promises. :)


-- 
Travis

Received on Friday, 8 June 2007 02:45:24 UTC