Re: Question about HTTP 2.0 priority

Thanks, Martin.  If a client can rely on two things, then a linked list is
not necessary:

1. the server will keep the priority tree information for closed streams
"long enough"
2. In the case of "(A1, A2, A3) -> 0; (B1, B2, B3) -> A1", if A1 completes
before A2, the server will apply any available resources to A2 and A3
before any of B1, B2, or B3.

Sounds like you're saying #1 is likely.

Can you confirm that #2 is also the behavior specified by the current draft?

Are there any implementations of HTTP 2 priority semantics in the wild?  Do
we have any real-world experience with how they work?  Will Chan argues
compellingly that prioritization is a crucial part of SPDY [1] -- where 3
bits has been precise enough for basic browser use cases -- and it seems
the HTTP 2 stream priority model originates from his deck Considerations
for HTTP/2 Prioritization [2].

What's your over-under on whether a future protocol or version of HTTP 2
would support numeric priorities in addition to or in lieu of the stream
dependency model?

I ask because I'm simultaneously pushing to have a request prioritization
API added to browsers, and it seems a bit optimistic for the API exposed to
JavaScript to map directly to HTTP 2 semantics.

[1] https://insouciant.org/tech/prioritization-is-critical-to-spdy/
[2]
https://docs.google.com/presentation/d/1OfgPJsW6P7pky5PiyEzBNZnf5dWXq-y19ReSSg6BIeM/pub


On Tue, Oct 7, 2014 at 1:34 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 6 October 2014 22:48, Chad Austin <caustin@gmail.com> wrote:
> > Are you suggesting that either the client, server, or both keep it
> around?
> > Does it matter if it's half closed?
>
> Well, a client that knows it's not going to use a stream as a basis
> for prioritization can discard the state immediately.  A server
> doesn't have that opportunity, so it has to use some heuristics to
> determine what to keep and what to delete.
>
> The point is that prioritization state isn't strictly tied to stream
> state.  If stream 7 depends - or could depend - on stream 5, stream 5
> might be closed at the server when initial or updated priority
> information for stream 7 arrives.  If the server cares about
> respecting prioritization for stream 7, it had best find a way to keep
> stream 5 in its priority graph somehow.
>



-- 
Chad Austin
http://chadaustin.me