W3C home > Mailing lists > Public > public-respimg@w3.org > June 2013

Re: A question about the discussions so far

From: Adam van den Hoven <adam@littlefyr.com>
Date: Thu, 27 Jun 2013 16:19:28 -0700
Message-ID: <CAAkH_kNtp8myouT9Bp4ZiO2M62r6aUPao53MDzv6hG11wn0DBw@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>

I'll go take a look at what I can do. It really is WELL outside my area of
expertise so I may have to recruit some outside help.

For the last question, I don't think that browsers necessarily need to
change AT ALL. The HTTP spec is explicit in not specifying resolution
mechanisms for 300 responses. I *think* that the layer handling HTTP simply
passes resources to the browser and leaves interpretation up to them. I
imagine that you could engineer the http layer such that it is aware of how
the request is being made (wifi vs cable vs 3g vs, device metrics, etc.) so
*it* would be in the best position to decide which file to retrieve. so the
browser would simply ask for resource foo, and the http layer would give it
some binary that satisfies that request (which just happens to be a lossy
webp with 10 quality, in this case). The optional change would have to be
to provide some mechanism for the HTTP layer to communicate the
*other*choices to the browser so some UI can be provided to the end
user to make
choices (for example something like the "save password" alert you see in
some browsers, but with more thought, I guess, since you have N images with
M variations) but the OS could provide a UI in its network settings to set
preference for different kinds of connections.


On Thu, Jun 27, 2013 at 3:18 PM, Marcos Caceres <w3c@marcosc.com> wrote:

> On Thursday, 27 June 2013 at 21:55, Adam van den Hoven wrote:
> > Marcos,
> >
> > Sure, but like I said, I'm not a browser/OS coder and that's really
> where any such polyfill/prototype would have to live.
> That's totally ok. Check out http://extensiblewebmanifesto.org for
> inspiration. Like I said, it doesn't need to be anything fancy. Just keep
> it simple.
> > I suppose I could cobble together a script in Ruby or NodeJS that works
> on the socket level which.
> That would be awesome (specially if done in NodeJS, as most of us here are
> JS coders… including me). We have an experiments repo over on github for
> exactly these kinds of experiments/tests:
> https://github.com/ResponsiveImagesCG/experiments
> There are plenty of people here who can review code, comment, etc.
> Node seems really well suited to this.
> > if my VERY shaky and fourth hand knowledge of the network layers is
> correct is the layer right below HTTP, would implement HTTP with my
> additions, but I'm not sure what that would accomplish.
> >
> > Unless you had something else in mind?
> It would be interesting to see how many requests are required to do what
> you are suggesting; if it's performant; how would a browser need to be
> changed to support your proposal etc.
Received on Thursday, 27 June 2013 23:19:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:09 UTC