Re: Some thoughts on server push and client pull

I believe we should keep it open for now, as clearly there is some work done on that front, and we should wait and see initial results.
We are also looking at this as a potential way to eliminate a roundtrip which is currently required in any other suggestion (where the client initiates the requests) - between the page and the embedded resources.


From: "William Chan (陈智昌)" <willchan@chromium.org<mailto:willchan@chromium.org>>
To: Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
Cc: Mike Belshe <mike@belshe.com<mailto:mike@belshe.com>>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com<mailto:Gabriel.Montenegro@microsoft.com>>, "ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: Some thoughts on server push and client pull

On Thu, Jun 7, 2012 at 9:54 AM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 7 June 2012 09:43, William Chan (陈智昌) <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:
> * Google is working on efforts to seriously deploy SPDY server push on our
> properties. I can't comment further on timeline, but I hope to provide data
> to guide our discussions, so let's not axe it just yet.
> * To my knowledge, Amazon is using it in their Silk browser. A proxy that
> uses server push is a fascinating use case, and it'd be cool to get data on
> that first.

I'm with Mike and Gabriel on this one.

It would be nice if HTTP/2.0 discussions could be scoped to exclude
discussions on new protocol semantics.  If you feel especially
attached to the idea of push, then my preference would be to see a new
draft on it.

Can you clarify what you mean by new protocol semantics? Does multiplexing count as a new protocol semantic? What's your proposed scope?

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