Re: HEADERS and flow control

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.

Received on Monday, 12 May 2014 18:16:32 UTC