Re: Design Issue: PUSH_PROMISE and Stream Priority

[Roberto Peon <[e-mail]>]

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