Re: Diminishing priorities in proposal

The real risk with further specificity here is that it encroaches on
implementation authority and autonomy.  Some of that autonomy is needed
because endpoints need to be able to handle abnormal load situations. In
those situations, dropping state might be the right answer.

I think that the best we can do is provide advice in this space anyhow.
>From an external perspective, it is almost impossible to validate the
behaviour of a peer anyway.

So, yes, LRU sounds like a great recommendation. Just don't expect a 'MUST'
to go it :)

We can't forbid the creation of dependencies on closed streams though. That
one's pure physics. Besides, I think that it will be very useful.
On Apr 16, 2014 6:14 PM, "David Krauss" <potswa@gmail.com> wrote:

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