Re: Design Issue: PUSH_PROMISE and Stream Priority

[James M Snell <[e-mail]>]

Then let's just say that,  currently, setting and using the priority on
push streams is out of scope. If we later determine that it is something
worth doing, we can make it in scope.
On Apr 27, 2013 2:43 PM, "Roberto Peon" <[e-mail]> wrote:

> There is a value, but I don't know if it is worth the 4 bytes. :)
> (The value is that now the client knows what the priority is, and has a
> better idea of when to change it if it is too far off from what it should
> be.)
> --=R
>
>
> On Sat, Apr 27, 2013 at 2:34 PM, James M Snell <[e-mail]> wrote:
>
>> I believe we're saying the same thing in different ways. Given the
>> language *currently* in the spec, the initiator of a stream can
>> specify a priority value for that stream and the recipient of the
>> stream needs to try to process those streams accordingly. What I'm
>> saying is that there is absolutely no value in allowing the server to
>> specify a value for the priority on a stream.
>>
>> On Sat, Apr 27, 2013 at 2:27 PM, Roberto Peon <[e-mail]> wrote:
>> > Sending of a message including a priority field != setting a priority.
>> >
>> > Server pushed streams have priority, but they are most likely to be set
>> by
>> > the client.
>> > I was understanding that we were asking a separate question: If it was
>> > worthwhile to have the server announce what priority it decided to use
>> for a
>> > pushed stream, and if so... when (e.g. at PUSH_PROMISE time, or, when
>> doing
>> > HEADERS).
>> >
>> > -=R
>> >
>> >
>> > On Sat, Apr 27, 2013 at 1:30 PM, James M Snell <[e-mail]>
>> wrote:
>> >>
>> >> I honestly cannot imagine any scenario where it would be useful or
>> >> desirable to allow the server to set a priority for pushed streams. My
>> >> preference would be for us to say that only client-initiated streams
>> >> have a priority. If we want to leave the door open later on, we can
>> >> say that priority on server-initiated streams is undefined and out of
>> >> scope rather than saying it's not allowed at all.
>> >>
>> >> On Fri, Apr 26, 2013 at 11:46 AM, Roberto Peon <[e-mail]>
>> wrote:
>> >> > Sorry I'm so slow-- internet connectivity is absolutely crud where I
>> am
>> >> > right now.
>> >> >
>> >> > What will the client do with the information a push_promise?
>> >> >  The headers, etc. are obvious--
>> >> > That data will prevent the client from creating another (redundant)
>> >> > request
>> >> > for the resource/
>> >> > If the client is given priority information with a push_promose,
>> perhaps
>> >> > this might cause the client to send a reprio message immediately to
>> >> > whatever
>> >> > the client wants, potentially before the server begins sending bytes
>> or
>> >> > creates the stream/reads the bytes. This assumes that the server even
>> >> > *knows* what the priority is at that point, which it may not.
>> >> >
>> >> > ... and, really, that is the only thing I can see the client doing
>> with
>> >> > that
>> >> > information. Does anyone see anything else it might do with it?
>> >> >
>> >> > does anyone think this is likely to be useful?
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Apr 26, 2013 at 11:35 AM, Martin Thomson
>> >> > <[e-mail]>
>> >> > wrote:
>> >> >>
>> >> >> On 26 April 2013 09:27, James M Snell <[e-mail]> wrote:
>> >> >> > For this there are several possible solutions:
>> >> >> >
>> >> >> >     A. We can simply say PUSH_PROMISE streams have no priority.
>> >> >> >     B. We can say that PUSH_PROMISE streams inherit the priority
>> of
>> >> >> > their parent, client-initiated stream
>> >> >> >     C. We can allow the server to use HEADERS+PRIORITY or a new
>> >> >> > Reprioritization Frame to establish the priority of a pushed
>> stream.
>> >> >>
>> >> >> That seems like a fair taxonomy.
>> >> >>
>> >> >> A is not possible.  There is no such thing as no priority.  Default
>> >> >> priority, perhaps.  At the point that you have to contend with
>> >> >> choosing between two streams, then you have prioritization.
>> >> >>
>> >> >
>> >
>> >
>>
>
>