Re: A question about the discussions so far

Yoav,

Thank you for your response.

On Thu, Jun 27, 2013 at 12:23 AM, Yoav Weiss <yoav@yoav.ws> wrote:

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

Perhaps, but (resource embedding aside) i think of it as an HTTP solution
because (a) I asked myself, "doesn't HTTP already deal with this?" and (b)
I'm suggesting that we use an infrequently used part of the spec. But I
suppose you're right.


>
>> 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?
>

Its different for the same reasons including SVG in HTML (recommendation
wise) is different than creating SVG as a separate entity. A markup
solution only solves the problem in one area, my solution potentially
solves it (and similar problems) for any area that uses the HTTP spec.


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

Meh. Sure, I could create a Java Taglib or what ever else in any other
language you like, but doing that at the
apache/nginx/webserver-of-your-choice level would mean text manipulation
 which is never speedy. I could *effectively* do this today with a script
that watches for certain changes and creates static version of what ever
this entity is and then use creative mod_rewrite rules. the different being
that markup is, these days, rarely static where as images are rarely
dynamic.

In the end, its not *quite* 6 of one, half dozen of the other, but its
close.

I should also say that the markup could work in tandem with what I'm
proposing since they approach the problem differently (developer knows what
he wants to show, UA knows what is efficient to show).


> 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 :)
>

I've quickly looked at CH and its a more refined version of a different
approach I was thinking of (which followed the other accepts headers and
indicated a preference for resources maximized for quality and dimension
and minimized for size, for example). Its limited (and for good reason, I
would suggest) to the visual characteristics of the UA although you could
expand it to include other relevant metrics like available bandwidth and
processing power (because maybe I'm only going to send the 12 fps version
of the video). Bandwidth is important because I am more tolerant of large
pretty images when I'm on the wifi at starbucks but if I'm on my 3G
network, not so much.

Using 300 responses doesn't preclude using CH.

I also think its rather impolite in our over surveillanced (I know its not
a word) to say to people who want to consume content I create, that they're
going to have to tell me all the gory details of their user agent in order
or its going to cost them on their phone bill. Personally, trading privacy
for an extra request may be worth it.

The main advantage is that markup can only be used where markup is used. It
does nothing to solve the problem in CSS (although I see there are
different additional/alternative solutions in CSS that have been proposed)
or JS (which *may* just generate markup but does not *necessarily *do so).
But it doesn't really address it in other places where we might find
images.

I think that solving the problem at the lowest possible layer of the
technology stack is desirable. So we *can* create animation by loading
dozens of png and using CSS to flip through them all, but animated GIFs or
movies are typically a more efficient solution for the majority of cases.

Also, the extra request issue isn't the biggest issue out there anyways, at
least not compared to total download size. You may need to take care in
what you do this with, but I think it might be satisfactory.