Subject: Server Push -> Cache Push?

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2014 10:57:44 +1100

I've noticed some confusion when I talk to people about server push, because it's not clear whether the server is being pushed to or from, and it doesn't make clear what's really happening.

What do people think about calling it "cache push" instead? To me, it gets to the heart of what's happening more clearly.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Hasan Khalil <[email-masked]>
Date: Thu, 30 Jan 2014 00:01:51 +0000

+1
On Wed, Jan 29, 2014 at 7:00 PM, Mark Nottingham <[email-masked]> wrote:

> I've noticed some confusion when I talk to people about server push,
> because it's not clear whether the server is being pushed to or from, and
> it doesn't make clear what's really happening.
>
> What do people think about calling it "cache push" instead? To me, it gets
> to the heart of what's happening more clearly.
>
> Cheers,
>
>
> --

---

From: Roberto Peon <[email-masked]>
Date: Wed, 29 Jan 2014 16:05:44 -0800

No, I think that would add to confusion, especially if we ever change the
spec to allow push of no-cache resources, etc.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 29 Jan 2014 16:06:32 -0800

I'd prefer if we called server originated or something like that if that is
the source of confusion.
On Jan 29, 2014 4:05 PM, "Roberto Peon" <[email-masked]> wrote:

>> What do people think about calling it "cache push" instead? To me, it
>> gets to the heart of what's happening more clearly.
>>
>> Cheers,
>>
>>
>> --

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2014 11:07:12 +1100

So, we've always talked about pushing into the cache; presumably, if you push something that's no-cache, it has a special state that allows it to be used once / within a browsing context, but it's still being pushed into the cache (indeed, the HTTP caching model already talks about caching things that are no-cache). 

On 30 Jan 2014, at 11:05 am, Roberto Peon <[email-masked]> wrote:

> No, I think that would add to confusion, especially if we ever change the spec to allow push of no-cache resources, etc.
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 30 Jan 2014 13:33:19 +1300

On 2014-01-30 13:07, Mark Nottingham wrote:
> So, we've always talked about pushing into the cache; presumably, if
> you push something that's no-cache, it has a special state that allows
> it to be used once / within a browsing context, but it's still being
> pushed into the cache (indeed, the HTTP caching model already talks
> about caching things that are no-cache).
> 

How about some analog of "prefetch"?  it is essentially a 
server-initiated prefetch operation after all.

Amos

---

From: Mike Belshe <[email-masked]>
Date: Wed, 29 Jan 2014 16:46:44 -0800

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

If we really think its a problem, maybe "server initiated streams"?

I think cache-push raises questions about which cache.  prefetch doesn't
seem to quite work because the client isn't fetching at all.

Overall, I like server push.

mike

On Wed, Jan 29, 2014 at 4:33 PM, Amos Jeffries <[email-masked]> wrote:

> How about some analog of "prefetch"?  it is essentially a server-initiated
> prefetch operation after all.
>
> Amos
>
>
>

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 30 Jan 2014 11:01:12 +1000

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

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 29 Jan 2014 17:43:03 -0800

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

I think re-naming at this point will just cause more confusion than it
alleviates.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2014 15:28:54 +1100

On 30 Jan 2014, at 12:43 pm, Jeff Pinner <[email-masked]> 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 <[email-masked]> 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".
> 
> 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

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 30 Jan 2014 10:15:08 +0100

How about "Response Push"?

//Stefan

>> Sorry, I tried to rewrite that last sentence a few times but I couldn't make it more readable.

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 30 Jan 2014 10:16:31 +0100

And then "Push Replies" instead of "Push Responses"?

<green/>bytes GmbH

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 30 Jan 2014 10:24:19 +0100 (CET)

On Thu, 30 Jan 2014, Mark Nottingham wrote:

> I've noticed some confusion when I talk to people about server push, because 
> it's not clear whether the server is being pushed to or from, and it doesn't 
> make clear what's really happening.
>

I think we've talked about "server push" long enough (from SPDY and onwards) 
that changing the term now risks _adding_ confusion for those who are in the 
loop and have learned what it is.

Also, I can't say I like any of the suggested alternative names as much.

-- 

  / daniel.haxx.se

---

From: Adrian Cole <[email-masked]>
Date: Thu, 30 Jan 2014 07:22:32 -0800

I have to admit cache push makes a hell of a lot more sense to the
unaclimated than "server push is a server initiated request typically used
to push resources into your cache"

I do see danger in type casting push for its first big use case, so ok with
explaining above when inevitable questions arise on what server push is.

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 30 Jan 2014 17:25:34 +0000

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.

Hervé.

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> 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?
> 
> 
> "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.)
> 
> 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 server-push is actually pretty well understood.  Those versant in HTTP
> recognize that a push to the server is also known as a "GET".
> >
> > 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.
> >