Re: A question about the discussions so far

Hi Adam,


> Great, the new guy is telling us its a hard problem. Someone get out the
> cluebat.
>

Get off our lawn, you Hippie :D


> What my question is, has anyone considered an HTTP solution?
>
> Specifically, it seems to me that you could use the "300 Multiple Choices"
> response and then document a new mime type that specifies the collection of
> representations for this resource and relevant metadata (dimensions, file
> size, format, quality, location, geographic location?). The user agent can
> then look at the metadata and decide which representation of the resource
> to use and then request that? So the UA could choose the high pixel, low
> quality small file size representation since is on a mobile network and has
> a high dpi screen (for example), but when it gets on WIFI it gets the
> bigger one. This is, again, not perfect since its hard for the UA to know
> how the resource will be used, but it can make more intelligent decisions
> in many cases. (and maybe we can use the equivalent of http's q property to
> indicate preferences, Location header aside)
>

I wouldn't consider what you're proposing an HTTP solution, but more in the
area of a "new meta format" solution. People have discussed it in the past.


> The value of this idea would seem to be that any type of resource could be
> handled this way (images, video, audio, code??) and it could be used
> anywhere (html, css, and js) without modifying them since its in the layer
> below. Its not ideal because you need a new mime type, although, the UAs
> could explicitly add it to their accepts list and servers could use that
> for content negotiation and not break existing browsers. It also requires
> extra HTTP requests. This can be mitigated by embedding the entity in the
> page using a data uri (i realize this departs from the model somewhat)
> based on content negotiation.
>

Indeed, it suffers from all the plagues you mention. I'm especially worried
about the extra request part. If you fight that by embedding the meta
format, how is that different than a markup solution?


>
> One could even create something like mod_responsive on the server side
> that used some convention to automatically handle this (say, create a
> folder called 'myfile.responsive' and the contents of the folder become the
> different representations of myfile) which would take away the complexity
> of this from content creators.
>

Very true. Also true for any kind of markup based solution. In my view,
once the proper markup solution is there, small sites with no backend
control can handcode it, while large sites can automate the entire process
of adding the final markup to the page. I don't see any specific advantages
a meta-format would have here over markup.


>
> I'm sure that there is something inherently flawed in my thinking, but I
> have met very few people who think too hard about HTTP (we all worked at
> that place where we 'broke the web' in one way or another) so I'm hoping
> that maybe there is something here to investigate. Not being a browser guy,
> I can't say much more than, "did anyone consider"?
>
>
An HTTP-based solution called "Client-Hints" is being discussed. It's a
server-side solution, so mainly adapted to CDNs and large sites that have
that level of control over their backend (which many independent devs
don't). Personally, I believe it covers some use-cases (e.g. the
"Optimization CDN that can't touch the HTML" case) better than markup based
solutions, and should be considered alongside (but not instead) of
client-side solutions.

If I'm missing anything, and your proposed solution has some advantages
over markup, don't be shy :)

Received on Thursday, 27 June 2013 07:23:38 UTC