W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

RE: Server Push -> Cache Push?

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Thu, 30 Jan 2014 17:25:34 +0000
To: Mark Nottingham <mnot@mnot.net>, Jeff Pinner <jpinner@twitter.com>
CC: Matthew Kerwin <matthew@kerwin.net.au>, Mike Belshe <mike@belshe.com>, Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532CCECCC@ADELE.crf.canon.fr>
I also think that the "Server Push" nomenclature has started to catch and would be reluctant to change it.

I think that the spec as it stands is a rather good compromise : it describes server push in a generic fashion, and hints that the intended usage is for updating the cache. It pose no restriction to other usage of this (as long as the request method is safe, and the response is cacheable).
Maybe we could be clearer that the intended usage is for updating the cache, but I think we should leave room for other usages, either in future versions, or in private implementations.


> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: jeudi 30 janvier 2014 05:29
> To: Jeff Pinner
> Cc: Matthew Kerwin; Mike Belshe; Amos Jeffries; httpbis mailing list
> Subject: Re: Server Push -> Cache Push?
> On 30 Jan 2014, at 12:43 pm, Jeff Pinner <jpinner@twitter.com> wrote:
> > I agree with Mike here:
> >
> > We've already started to build up the nomenclature / language around
> "Server Push" and "Server Hint" along with use-cases for server push that are
> outside of the HTTP caching model. (As an example, the current
> implementation in our iOS client is to issue a NSNotificationEvent and have the
> application treat it as if it issued the request.)
> Well, "server hint" is a *terrible* name, but that's a different argument.
> If we're talking about server-initiated streams in terms of use cases other than
> updating the cache, I start to get confused and concerned. How does the client
> differentiate between different uses? And, how does that fit into our charter
> (which says we shouldn't be inventing new features in this effort)?
> Maybe what's needed is a way to differentiated server-initiated streams *for*
> cache push from other, future uses of the mechanism.
> Regards,
> >
> > I think re-naming at this point will just cause more confusion than it
> alleviates.
> >
> >
> > On Wed, Jan 29, 2014 at 5:01 PM, Matthew Kerwin
> <matthew@kerwin.net.au> wrote:
> > On 30 January 2014 10:46, Mike Belshe <mike@belshe.com> wrote:
> > I think server-push is actually pretty well understood.  Those versant in HTTP
> recognize that a push to the server is also known as a "GET".
> >
> > That's a typo for "PUT", right?
> >
> > I agree that "server push" makes enough sense as it is, and "cache push" --
> while describing the only real use-case we currently have -- deters any future
> uses that may evolve.  If we were going for a verb that describes the action in a
> general case, it would be something like "preempt," since semantically the
> server is preempting a request. (Or possibly "anticipate.")  But who really wants
> to call it a "preemptive response"?
> >
> > Another thing I like about "server push" is that it hints at a possible future
> mechanism: "server pull."  I don't have a use for such a thing right now, but just
> having the possibility looming there in the language might trigger some clever
> person some day to see in it a solution to some problem they're having.
> >
> > Sorry, I tried to rewrite that last sentence a few times but I couldn't make it
> more readable.
> >
> > --
> >   Matthew Kerwin
> >   http://matthew.kerwin.net.au/
> >
> --
> Mark Nottingham   http://www.mnot.net/
Received on Thursday, 30 January 2014 17:28:11 UTC

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