Re: h2 frame layout

I don't see any point in engaging in a self-defeatist argument over what can be changed. There are no implementations of the final protocol because the spec has an interop break built into the versioning. 

A WG last call is based on what the group has produced so far, which means the suggestion should be evaluated on its relative merit when compared to the current spec and the willingness of implementors to implement. Of course, if most of the people here just want to be done and don't care about the quality of the protocol, then it will be a very interesting trip through the IESG last call process.

BTW, none of those suggestions change semantics. They might enable additional semantics later on, but it should be trivial to change an implementation right now. All I change is where to write or read the same data. Also, I only care about 64bit alignment within the messaging buffers.

....Roy


> On Aug 29, 2014, at 10:56 PM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> Roy,
> 
> there have been several contributors (including myself) who have come into the process late and looked at the framing layer and had a similar reaction to what you have expressed.          For my own part,  I strongly argued against the framing flags being a function of frame type and I expressed my belief that it is a mistake to conflate the semantics of HTTP with the framing layer.
> 
> As each of these new views has come in, it has woken up some other voices with lingering levels of discontent towards the design and a new round of debating some  design decisions results.   Unfortunately none of the iterations of this pattern have been able to convince enough of the voices here to achieve consensus to change some fundamental design decisions that drive what has been described as the "uglyness" of the framing layer.       I think the problem is that none of the new voices have been able to inspire an appetite for wholesale change and have instead resorted to try to "fix" the protocol by arguing for change bit by bit or byte by byte.
> 
> So while there have been many minor improvements in the last few iterations of the draft, I do not think that some of the fundamental problems with the framing layer have been fixed and when new eyes look at tit they still have a WTF moment with some elements of it.
> 
> Your own proposals represent both ends of the spectrum:
> 
> Your proposal A is just a trim of the current framing layer to send the same semantics over 64 bytes rather than 72.  I've got no objections to that, but note that making it look data aligned will not actually make it data aligned unless padding is not a function of frame type and we require all payloads to be padded to a word boundary, so I think more substantial change is necessary to achieve any more substantial than a saving of 1 byte per frame.   So it is a bit by bit improvement, but doesn't "fix" the framing.
> 
> Your proposal B is a significant change of semantic.  I totally agree that defining concepts like END_STREAM independently to frame type is a really good idea, as this would facilitate carrying alternate semantics like websocket and maybe even waka?    However, all previous attempts to achieve consensus that this is something that should be fixed has failed, I think mostly because the WG was wrongly chartered to primarily consider HTTP semantics.   If it had been chartered to support multiple web semantics: HTTP, Websocket and potential future web semantics, then we might have ended up with a better framing layer that is not dependent on frame type or HTTP semantics.
> 
> As much as I would like to see significant changes to the framing layer, I don't think it is worthwhile reopening that can of worms unless we firstly revisit the charter.     If essentially all we have to transport is HTTP in it's current usage patterns, then the argument always devolves to that it doesn't matter if the framing layer is ugly, fragile, inextensible, special purpose etc.   We have made the mistake of trying to generalise from a single example, so the non-HTTP parts of the protocol such as unused flags and frame types are highly unlikely to be usable for anything that does not pretend to be HTTP.
> 
> 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.