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

Re: Some thoughts on server push and client pull

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 8 Jun 2012 10:27:14 -0700
Message-ID: <CABkgnnVGSM8QqxdyAxfjA9ymmH-GDD1wFauzKs1ZzhK8kzr=ZQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Mike Belshe <mike@belshe.com>, Alek Storm <alek.storm@gmail.com>, Jonathan Silvera <jsilvera@microsoft.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Matthew Cox <macox@microsoft.com>, Ivan Pashov <ivanpash@microsoft.com>, Osama Mazahir <OSAMAM@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>
On 8 June 2012 00:16, Mark Nottingham <mnot@mnot.net> wrote:
> WRT SPDY and server push, I'd suggest keeping it in, but making sure it's separable, so that the decision can be delayed until you have more data.

I don't know.  Not to abuse the analogy, but I might like giant wooden
horses and still have an aversion to having strange men inside my city
walls.  Or, from another angle, it's going to be hard enough to get
the simple things right, why add more stuff.  We're here to solve
head-of-line blocking, not to create an standard analogue of the same.

The idea that this is a once-in-a-lifetime opportunity is a fallacy.
If you care about this feature, then make sure that no changes ruin
the protocol such that push couldn't be added.

The trade-offs involved with binary serialization/compression,
multiplexing and the other properties are well enough understood to
retain those.  On the other hand, the unilateral delivery of
unrequested content is not.

Received on Friday, 8 June 2012 17:27:43 UTC

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