Re: Server push limited to cache priming?

I'm not too worried about this.
The types of things that would really use server-initiated streams but not
push something into a cache are the kinds of things best served with the
WebSocket API or something similar.
-=R


On Wed, Mar 19, 2014 at 6:07 PM, Adrien de Croy <adrien@qbik.com> wrote:

>
> I don't think backward compatibilty means nothing new can be allowed.  It
> just means everything old must still be supported.  If a pathway doesn't
> support all new features (e.g. a 1.1 gateway in the chain), then that is a
> different issue, and some new features may not be available in that
> deployment case, but shouldn't be prohibited in the spec.
>
> Cheers
>
> Adrien
>
>
> ------ Original Message ------
> From: "Mark Nottingham" <mnot@mnot.net>
> To: "Martin Thomson" <martin.thomson@gmail.com>
> Cc: "William Chan (陈智昌)" <willchan@chromium.org>; "Daniel Sommermann" <
> dcsommer@fb.com>; "HTTP Working Group" <ietf-http-wg@w3.org>
> Sent: 20/03/2014 1:51:40 p.m.
> Subject: Re: Server push limited to cache priming?
>
>  Speaking personally --
>>
>> I'm going to continue to push back on non-caching uses of server push in
>> HTTP/2; our charter explicitly tells us to be semantically
>> backwards-compatible with HTTP/1, and that means no new semantics. The only
>> way to fit server push into HTTP's existing semantics is to consider it a
>> cache update.
>>
>> In other words, if you overload server push to mean "async message" and
>> use a new client API to get them, that's not a HTTP API. It'd also
>> necessitate figuring out how to distinguish those updates from pushes that
>> *are* intended for the cache.
>>
>> OTOH it should be possible to layer async messaging over caching in a way
>> that takes advantage of server push, somewhat like COMET does. I've started
>> to sketch out one mechanism that would contribute to that here:
>>   http://tools.ietf.org/html/draft-nottingham-http-patch-
>> status-00#appendix-A
>>
>> Cheers,
>>
>>
>>
>>
>> On 20 Mar 2014, at 4:30 am, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>
>>   On 19 March 2014 09:56, William Chan (陈智昌) <willchan@chromium.org>
>>> wrote:
>>>
>>>>  This is an unfortunate part of having perhaps too (current?)
>>>> browser-centric
>>>>  a view in some of our discussions.
>>>>
>>>
>>>  I don't think that it's that at all. I know that browsers and browser
>>>  use cases dominate the discussion often, but I believe that this
>>>  decision was made for another reason.
>>>
>>>  The reason, as I understand it, relates to the ability of a client to
>>>  act upon a response when it is received. If you push a response that
>>>  is not expected and it's not cacheable, then - absent some sort of
>>>  eventing API - it has to be discarded. This is more a symptom of
>>>  wanting to minimize the delta for using applications, and a concern
>>>  that we don't completely understand all the implications of a choice
>>>  to allow non-cacheable responses. Once we have eventing APIs, then
>>>  perhaps we can lift the restriction, but it's harder to remove
>>>  functionality if we made a mistake.
>>>
>>>
>> --
>> Mark Nottingham http://www.mnot.net/
>>
>>
>>
>>
>>
>
>