Re: Large Frame Proposal

On 11 July 2014 13:17, Roberto Peon <grmocg@gmail.com> wrote:

> I think you're arguing for things at the semantic layer, not he framing
> layer-- right now one of the proposals *is* that we treat headers
> differently by only allowing them to exist in one frame, which is not how
> data is treated.


True.  I'm currently advocating for two contradictory positions as I can
see two viable options for headers:

a) They are transported in a dedicated frame type, which must be large
enough to carry all conceivable headers - 24 bit length minimum, but 31bit
better.    This does not move headers to the semantic layer (where they
belong) but is a minimal change to the current draft.  I can live with it.

b) They are transported exactly like data (they are after all just
application data that is not important to framing).  I'd still like to see
a large max frame size, but could probably live with 16 bits even if I
think that would be extremely short sighted.   This is a much bigger change
to the draft and I don't think there is the will to make such a big change
- but I would like to live with it if there were.


What is not viable for me is:

c) Have a multi frame header transport mechanism for headers that is
entirely different to the multi frame transport mechanism for data, with
different rules for flow control and interleaving and expect them to live
side by side without confusion, bugs and QoS issues.  Frame size is
irrelevant in this situation as the solution sucks regardless of frame
size. This is h2-13

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.