Re: Diminishing priorities in proposal

On 2014–04–17, at 7:21 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> So yes, there is a problem.  The problem is premature loss of
> information.  

Well, the other problem is that the revision (pull request) still mentions dependencies in the CLOSED state, so something’s gotta give.

> We have to allow servers to limit their state commitment, and having a
> specified practice for handling a very common case somewhat gracefully
> is a good idea.  

It’s a good idea, but not necessarily a must-have for an initial release. The amount of state is small. I think it can be managed well enough. Perhaps a LRU cache is a good approximation of behavior?

> Including a warning about the consequences of early
> tree pruning is probably the best that can be done.

A set of guidelines for clients to judge the validity of a closed stream as a dependency would be nice. I’m not even sure how to specify this, though. (And I didn’t have any idea how to maintain the set of priority groups, either.) The server ideally should maintain a closed stream/priority group for each tab, and the client re-prioritizes those as the user clicks different tabs. But, there is no limit to the number of tabs in a window, and sloppy users really do open a lot.

I recall my earlier proposal where the server sends a reply PRIORITY to override a client request. This could be a valid pattern for any received PRIORITY that the server cannot service…

Received on Thursday, 17 April 2014 01:15:33 UTC