Re: #537: Remove segments (consensus call)

On Tue, Jul 1, 2014 at 11:20 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014–07–02, at 2:12 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> > Segments are not redundant with midstream headers.
> > Headers potentially have semantic meaning, even when 'empty’.
>
> There is no other difference. (I think I accounted for that, the last
> couple times I explained this.)
>
> If segments were gone, applications would simply use headers to express
> the same thing. Compatibility is not currently an issue. (Semantic
> complexity is an issue, but not in a good way. I don’t think the potential
> for application discrimination is a counterargument at all to Mark’s
> original question.)
>

That is a work-around and not an equivalent. It precludes the expression of
empty metadata, requires more bytes, adds complexity and potentially
requires modification of the compressor state, likely rendering the
compressor less effective.

There are two use-cases for it, as explained before.
Proxies/gateways which interpret in the session layer (e.g. loadbalancers)
should not.


> > For my part, I still see that END_SEGMENT or something similar provides
> for interesting characteristics for HTTP2->1 gateways in allowing chunks to
> be reproduced (and we know that there are issues there) as well as allowing
> the coalescing/tunneling of protocols such as WS onto the connection,
> making them more viable.
>
> Could the same be done with an empty midstream header set? It must be
> relayed by HTTP/2 intermediaries, but may be stripped when translating to
> HTTP/1.1.
>
>
All the arguments about not passing END_SEGMENT exist for any midstream
HEADER, so to me the difference isn't compelling.
-=R