Re: PRIORITY extension

I don't really understand why the flow control mechanism is not sufficient
to implement priority?

My understanding of the use-case for priority is when a client received
many push promises and/or makes make parallel requests, then it can
stipulate which ones it wants to receive first.  Why can't it use flow
control windows to achieve this?

Is it the case that priority is needed for small resources that will not
need a window update to be sent?   But in that case, if you have 80
resources being pushed at you, 70 of them are probably in single frames so
by the time the client knows which ones it wants first they have probably
already been sent / queued etc.?

ie in all the scenarios that I can imagine, I can see flow control windows
being able to be used to control priority just as well as priority frames.

Perhaps somebody can writeup a few good examples of how they see priority
helping where flow control cannot?

thanks








On 14 July 2014 10:58, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

>
> 2014/07/14 9:46 "Patrick McManus" <pmcmanus@mozilla.com>:
>
> >
> > The whole point of h2 is a prioritized, muxxed protocol with improved
> connection handling.
> >
> > Let's complete that work.
> >
>
> I couldn't agree more.
> Removing PRIORITY is really bad idea.
>
> Best regards,
> Tatsuhiro Tsujikawa
>
> > -P
> >
> >
> >
> > On Sun, Jul 13, 2014 at 7:55 PM, David Krauss <potswa@gmail.com> wrote:
> >>
> >>
> >> On 2014–07–13, at 4:46 AM, K.Morgan@iaea.org wrote:
> >>
> >> > As far as I can tell, everything in h2-13 related to PRIORITY is
> completely optional (please correct me if I'm wrong).
> >> >
> >> > I've repeatedly seen arguments against adding anything optional to
> the spec. So why does PRIORITY get a pass? If it's truly optional, it could
> easily be moved to a separate RFC as an extension.
> >>
> >> I’m in favor.
> >>
> >> Clients wishing to send PRIORITY should know whether the server is just
> going to ignore it. It’s a good signal to use another prioritization
> strategy, for example by reducing concurrency (start streams later).
> >>
> >> Also, it’s had the most churn of any part of the spec and practical
> experience will take more time. Extension status will enable faster
> evolution.
> >>
> >>
> >
>



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.