Re: Design Issue: PUSH_PROMISE and Stream Priority

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 <grmocg@gmail.com> 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 <martin.thomson@gmail.com>
> wrote:
>>
>> On 26 April 2013 09:27, James M Snell <jasnell@gmail.com> 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.
>>
>

Received on Saturday, 27 April 2013 20:31:21 UTC