W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: HTTP/2 Priorities Proposal

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Fri, 18 Apr 2014 15:11:12 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Jeff Pinner <jpinner@twitter.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532D45E6C@ADELE.crf.canon.fr>
I rather like the overall simplification of the proposal.

I however have one concern: priority groups are structures that the client knows will be persisted by the server. As such, a client changing the priority of a group is certain that the server will be able to apply it.
This is useful for example for the tab focusing use-case. Assuming the client creates a priority group for each tab, it can easily change the priorities for the different tabs when the user changes the foreground tab, and is certain that these changes will be applied by the server.
With the proposal, the client has no certainty that the server has retained enough information to apply priority changes for a tab switching. It can update the priorities (the weight) for the streams at the top of the sub-trees corresponding to each tab, but the server may already have discarded all information regarding these streams and be unable to apply the priority changes.

A possible workaround would be to strongly suggest to server implementations that keeping information about top level streams is helpful to client that want to reprioritize a whole set of streams.


> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: vendredi 18 avril 2014 03:18
> To: Jeff Pinner
> Cc: HTTP Working Group
> Subject: Re: HTTP/2 Priorities Proposal
> On 8 April 2014 16:23, Jeff Pinner <jpinner@twitter.com> wrote:
> > I believe it would be simpler (both conceptually and in practice) to
> > slightly modify the priority structure.
> Looking back at this, this proposal makes the following two changes:
> 1. removes priority groups
> 2. adds weights at all levels of the dependency tree (as opposed to
> just at the grouping layer)
> The first removes some capabilities, as has been noted elsewhere.  The
> ability to create and weight a named thing that is independent of any
> stream is a features, but it's also complexity.  This is a net
> complexity loss.
> The second is arguably an expansion of the capabilities, which could
> be perceived as an increase in complexity, except for the fact that it
> basically just removes a special case.  This is an increase in
> capability, which might be perceived equally as an increase in
> complexity or an increase in uniformity.
> Personally, I'd like to hear more of what others think about this.
> The comments I've seen are generally favourable, but I know that Mike
> wants more time to consider the implications.
> Is there anyone else on the fence, or - probably more importantly -
> opposed to making this change?

Received on Friday, 18 April 2014 15:11:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC