Re: HEADERS and flow control

Care to explain which part of this would be half-hearted?

On Mon May 12 2014 at 2:16:04 PM, James M Snell <jasnell@gmail.com> wrote:

> Honestly, if we had properly dealt with this a year ago like I had
> suggested it would be a non-issue today. I certainly sympathize with
> the use case, but given the state of things as they stand now, I'm not
> convinced that it's worthwhile trying to half-heartedly jam this back
> in now.
>
> On Mon, May 12, 2014 at 10:32 AM, Roberto Peon <grmocg@gmail.com> wrote:
> > We are unable to express something in http2 that we previously could with
> > http/1 pipelining/and/or http/1.1 chunking.
> >
> > That is not satisfactory.
> >
> > -=R
> >
> > On May 12, 2014 9:57 AM, "Martin Thomson" <martin.thomson@gmail.com>
> wrote:
> >>
> >> I've been thinking about this over the weekend and I remain unmoved by
> >> this thread.  I think that there's a kernel of something here, but I
> >> remain unconvinced that this is something that we need to do anything
> >> about this.
> >>
> >> Basically, it's not HTTP.
> >>
> >> On 9 May 2014 17:02, Roberto Peon <grmocg@gmail.com> wrote:
> >> > an expression of sequencing
> >>
> >> I think that this is key.  RPC protocols often depend on some sort of
> >> ordering semantic in order to get decent throughput.  That and layer
> >> upon layer of metadata.  The protocol Roberto looks a little like
> >> HTTP, maybe even to the point of being a changeling [1].  I think that
> >> we need to discuss to what extent we want to support changelings.
> >>
> >> The alternative is that Roberto's unnamed customers need to think
> >> about doing option (h) and put every RPC call on its own stream, using
> >> header fields or some other mechanism to express dependencies [2].
> >> And yes, I'm aware that this isn't the only externality in play.
> >>
> >> --Martin
> >>
> >> [1] https://en.wikipedia.org/wiki/Changeling
> >> [2] Of course that this will cause some intermediaries to have
> >> non-standard hacks in them to support backends that rely on getting
> >> dependent streams at the same backend instance.  And that sucks, but I
> >> believe that to be the de facto state of these sorts of intermediary
> >> anyway.
>