Re: #537: Remove segments (consensus call)

I worry we'll regret losing segments and mid-stream HEADERS (or METADATA or
the like).

The hop-by-hop HTTP use-cases (eg, in ICAP and for data integrity
protection) seem like one where we can re-introduce them fine with
extensions.  However the end-to-end cases (WebSockets) seem like they will
be harder to get intermediates to support well in the long-term if we don't
define them now.

Similarly, when WebSockets and the like do implement something, the
implementations
would presumably be much more consistent if the framing layer has a clearly
defined
mechanism for supporting them so that each one of them doesn't result in a
new
slightly different frame type with slightly different formatting and
semantics.

       Erik



On Tue, Jul 15, 2014 at 11:15 PM, Roberto Peon <grmocg@gmail.com> wrote:

> I'd say that the current stance is that anything which isn't part of the
> past set of usecases for http will not be considered for h2.
>
> This is disappointing, but there it is. It is difficult to do anything
> forward looking in committee, regardless of its venue or the talent of its
> members.
> On Jul 15, 2014 6:55 PM, "Yutaka Hirano" <yhirano@google.com> wrote:
>
>> I'm a bit behind, can you tell me what you mean by "semantic-free"
>> HEADERS?
>> It the current stance for extensions (such as WebSocket) "Do not abuse
>> HTTP related frames. Instead, define and use extension-specific frames"?
>>
>>
>>
>>
>> On Wed, Jul 16, 2014 at 8:57 AM, Greg Wilkins <gregw@intalio.com> wrote:
>>
>>>
>>> On 16 July 2014 09:46, Martin Thomson <martin.thomson@gmail.com> wrote:
>>>
>>>> You can try to start h2 and then upgrade to websockets if the ALPN
>>>> negotiation selects http1.1.
>>>>
>>>
>>> Currently this kind if decision is made above the browser in javascript
>>> libraries that have to decide if they are going to use websocket or long
>>> polling.  If they use long polling, for h1 they have to be aware of
>>> connection limits and currently some assume 2, while others have been
>>> updated to 6.  A much higher connection==stream limit will need to be
>>> applied if long polling over h2.     But these frameworks don't have the
>>> ability to take part in h2/upgrade negotiations and any knowledge they get
>>> about protocol versions will be late.  They probably don't have access to
>>> max stream settings, so will be guessing again.
>>>
>>> Now if h2 had supported websocket semantics from day 1, then these
>>> libraries could have just handed over the messages to the browser and it
>>> would be up to the browser to work out the best way to transport.
>>>
>>> Anyway.... I've made my point (several times) that I think it was a
>>> mistake for the charter to not support all the current web semantics.  I
>>> guess that horse bolted a long time ago.
>>>
>>> cheers
>>>
>>>
>>>
>>> --
>>> 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.
>>>
>>
>>