Re: Call for Consensus: HTTP/2 Priorities Proposal

+1 to include Jeff's proposal. Primary complexity of dealing with stream
dependency tree is not reduced much, but framing gets simpler and we don't
need stream group.

Best regards,
Tatsuhiro Tsujikawa
 2014/04/18 15:37 "Mark Nottingham" <mnot@mnot.net>:

> To magnify this a bit --
>
> So far, I've heard reactions that range from neutrality to general support
> for Jeff's proposal <https://github.com/http2/http2-spec/pull/453>.
>
> We're late for declaring our next implementation draft, and have a few
> issues to clean up. So, unless I hear significant pushback on doing so in
> the next ~3 days, we'll incorporate Jeff's pull request into -12 and call
> that an implementation draft (along with any other changes we agree upon).
>
> Keep in mind that this is deciding what to put into the next
> implementation draft -- we may still add to it or even change it based upon
> our experience with it and NYC. That said, we also have a strong desire to
> finish this work, so we don't have too many iterations to play with it.
>
> Regards,
>
>
>
> On 18 Apr 2014, at 11:17 am, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> > 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.
>
> I think you mean "improvement" here...
>
>
> > 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?
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>