W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: Some thoughts on server push and client pull

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Thu, 07 Jun 2012 13:19:04 -0400
Message-ID: <1339089544.3545.105.camel@ds9>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mike Belshe <mike@belshe.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Thu, 2012-06-07 at 10:07 -0700, William Chan (陈智昌) wrote:

> I understand the desire to split out server push into a separate
> draft / extension. If we don't have data to support push, then by all
> means we should drop it.

imo it doesn't need to be proven out at the early ID stage. Its totally
fair to take an idea like Push and get some experience with it - and
doing that in the open in a inter-vendor way is better experience (and
that realistically needs an ID). If it harms the implementation rate,
that's a data point right there :)

I'm pessimistic about push mostly because I don't think the upside is
very impressive for it compared to its complexity (especially the
complexity required to address the valid raised concerns). But I'm still
very open minded - and I've got half of a firefox implementation on my
back burner to try and add to the experience-gathering portion of the

Its quite possible that push will create a disincentive to spriting, and
inlining js/css. Doing that would actually have an improved impact on
caching (presuming push can be adapted to caching - which I think it
can), and fine grained resource reuse.. those things have the potential
to be larger net wins for the web than the 1 RTT per page load push
typically yields.

>  The main concern I have is with regards to treating push as an
> optional feature / extension. As many of us have stated repeatedly on
> this mailing list, many things that are optional simply become
> unusable in real, public deployments.
>         --Martin
Received on Thursday, 7 June 2012 17:19:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC