I don't disagree-- that would be nice. :) I just want to be sure that we're not tying server push to a requirement that we generate a usable refinement (e.g. cache hinting)-- If we do that, we again force people to inline, which wouldn't be anywhere as easy to refine in the future. -=R On Tue, Jan 22, 2013 at 6:53 AM, Patrick McManus <pmcmanus@mozilla.com>wrote: > honestly I do think push can, and should, be refined a bit for reasons of > bandwidth (and cost) conservation in some envs. Even the notiion of > Have-Subresources:: etag set (or hash of set, or whatever) probly gets a > long way. > > > > On Mon, Jan 21, 2013 at 11:20 PM, Ilya Grigorik <ilya@igvita.com> wrote: > >> >> On Mon, Jan 21, 2013 at 7:35 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >>> Also, it'd be REALLY nice to think about about what this means for >>> responsive design; e.g., if I'm a mobile, I don't need the desktop >>> stylesheet, and maybe not some of those images too. So, how does that work >>> in a push world? >> >> >> I think these are mostly orthogonal. While its a good exercise to think >> about this, I don't think this needs to be an explicit goal for HTTP 2.0. >> The HTML5 spec specifically says that the resources should be downloaded, >> even if the media-query breakpoint does not match (ex, print stylesheet, >> etc). In other words, we need to first resolve these questions in HTML5 >> specs, before we worry about the transport.. otherwise cart before the >> horse... >> >> And, all of that aside, we do have a solution: serve the appropriate HTML >> to different clients. (just add a Vary: User-Agent.. oh wait - *ducks* :-)) >> >> ig >> > >
Received on Tuesday, 22 January 2013 15:17:42 UTC