Re: Design Issue: PUSH_PROMISE and Stream Priority

[Roberto Peon <[e-mail]>]

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