Re: BLOCKED frame specification

I am not particularly interested in implementing BLOCKED, whether it holds
up the schedule or not.


On Wed, Apr 9, 2014 at 1:38 PM, Rob Trace <Rob.Trace@microsoft.com> wrote:

>  The BLOCKED frame is not something we are interested in and would rather
> not add another late feature to the spec.  The standard is already slipping
> the schedule and we need to stop adding to the spec.
>
>
>
> Thanks!!
>
>
>
> -Rob
>
>
>
> *From:* Roberto Peon [mailto:grmocg@gmail.com]
> *Sent:* Wednesday, April 9, 2014 2:30 AM
> *To:* Yoav Nir
> *Cc:* David Krauss; HTTP Working Group
> *Subject:* Re: BLOCKED frame specification
>
>
>
> imho, this is useful for tuning, not just debugging.
>
>
>
> And we've found that tuning is annoyingly difficult to get right.
>
>
>
> Obviously I want this, in case that wasn't common knowledge already :)
>
> -=R
>
>
>
> On Wed, Apr 9, 2014 at 2:17 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>
> On Apr 9, 2014, at 12:02 PM, David Krauss <potswa@gmail.com> wrote:
>
> >
> > On 2014-04-09, at 4:59 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> >
> >> That only tells me if the connection is working, not if the resources
> are not coming because of some server issue (like trouble connecting to a
> back-end database) or because of flow control.
> >
> > Use the implementation-defined payload value. It's not portable but you
> don't need portability for debugging.
>
> Looking at section 6.7 of -11 I don't see any implementation-defined
> payload value, just some opaque data that the receiver should copy into its
> response.
>
> Even if there was, I would be debugging my implementation against some
> other implementation. Not against my own.
>
> Yoav
>
>
>



-- 
Peace,
  -Nick