Re: A question about the discussions so far

Hi Adam,  

On Thursday, June 27, 2013 at 12:31 AM, Adam van den Hoven wrote:

> Pardon me if this has already been addressed but I couldn't find any reference to this from a Google search so maybe its new.  
>  
> The way I see the responsive images problem is one of responsibilities. The developer knows what he wants to show but only the user agent knows what its capabilities are. Ideally we would give the user agent the ability to request the correct representation of a resource based on a context only it knows (hardware, network, physical location...)..  
>  
> In general it seems that most solutions put the onus on the developer to make optimal decisions about what representations to use when. But I think that we're going to run into the unavoidable problem of how do you efficiently declare representations for every possible situation? There are too many different variables to consider to do it justice.  
>  
> Great, the new guy is telling us its a hard problem. Someone get out the cluebat.
heh. We all need a smack with the cluebat… don't worry :)   
>  
>  
> What my question is, has anyone considered an HTTP solution?
Yes, see client hints:  
https://github.com/igrigorik/http-client-hints  

> 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?).
IIRC, 300 is not great, because when given multiple choices, it's the user that needs to make the choice.   
> 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)

Right, but it still needs to make a choice from a choice derived from a HTTP request (i.e., that's two requests, which is not great). Allowing the client to have more information up front avoids that.   
>  
> 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.

Depends on the hinting provided to the server. There is another downside, pointed to by Ilya Grigorik, which is sending more data with each request. Not a lot, but a bit (Ilya says about 10-20 bytes).  
> 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.

I missed the new mime type bit? Where does that come in?   
> It also requires extra HTTP requests.

Yep.   
> 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.

This is adding a lot of complexity, IMO.   
>  
> 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.

The research we have done within the group shows that a significant number of devs don't have control over the server side. Solutions that rely too much on the server    
>  
> 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.  

Don't worry, we have Ilya kicking around here to remind us about HTTP… he is also involved with HTTP 2.0.   
> Not being a browser guy, I can't say much more than, "did anyone consider"?  
>  

We have and we certainly need to keep investigating the viability of these options.  

Kind regards,  
Marcos  
--  
Marcos Caceres

Received on Thursday, 27 June 2013 07:30:30 UTC