Re: Design Issue: PUSH_PROMISE and Stream Priority

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

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