Re: HTTP/2 Priorities Proposal

I have no current plans to leverage something like this, but I could
conceive of needing this. My two cents is that if it's any non-trivial
complexity, don't support it, since it can already be done by other means.
But if it's trivial complexity, then sure, maybe we'll use it. And by
complexity, I don't mean just implementation complexity, but also spec
complexity. Cheers.


On Tue, Apr 15, 2014 at 9:56 AM, Jeff Pinner <jpinner@twitter.com> wrote:

> A question was raised on the pull request of whether or not we should
> allow exclusive root dependencies, i.e. whether or not to allow inserting a
> stream between the connection and all of its children.
>
> Client authors, do you thing this is an important use case to support with
> no additional frame overhead?
>
> (I will note that this can still be achieved with a non-exclusive
> dependency followed by re-prioritizing all children onto the new stream.)
>
>
> On Mon, Apr 14, 2014 at 3:47 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> For those who haven't seen it:
>>   https://github.com/http2/http2-spec/pull/453
>>
>> Cheers,
>>
>>
>> On 10 Apr 2014, at 3:46 am, Jeff Pinner <jpinner@twitter.com> wrote:
>>
>> > Are there any objections to me opening a pull requests with these
>> changes as a more concrete proposal?
>> >
>> >
>> > On Wed, Apr 9, 2014 at 8:05 AM, Jeff Pinner <jpinner@twitter.com>
>> wrote:
>> > To change all weights, we have to issue PRIORITY frames for each root.
>> >
>> >
>> > Yes, changing the weight of a stream would require issuing a PRIORITY
>> frame for each stream. With this proposal you cannot do it by changing the
>> weight of the group.
>> >
>> > I believe that this is an acceptable tradeoff.
>> >
>> > Let me give a similar example where we reached the same conclusion:
>> >
>> > At one point we considered whether or not RST_STREAM should have an
>> ASSOCIATED flag. The argument was that the server could send PUSH_PROMISE
>> frames for some stream that the client did not want to receive pushes for.
>> With the flag, the client could reset all of those streams with a single
>> frame. We decided it was perfectly acceptable to send one frame for each
>> stream and dropped the flag.
>> >
>> > With this change, to change the weight of multiple streams, you must
>> issue one frame per stream, but IMHO this is worth it given the reduced
>> complexity of the change, and more importantly, the ability that this
>> change introduces of being able to completely proxy the priority
>> information.
>> >
>> >
>> >
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>