Re: Design Issue: PUSH_PROMISE and Stream Priority

[Roberto Peon <[e-mail]>]

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