Re: Large Frame Proposal

On 8 July 2014 03:42, Martin Thomson <martin.thomson@gmail.com> wrote:

> My one big reservation is with the addition to WINDOW_UPDATE.  I think
> that it's unnecessary complexity.  The other changes you make are
> well-enough supported, but this seems like feature creep to me.
> Having to track a limit on each stream is more state and complexity.
> And making it optional and ignorable means that you've created an
> optional feature that is optional, which is a poor way to guarantee
> that implementations will provide and respect it.
>


Martin,

well we could make it compulsory if that makes the proposal more likely to
be accepted :) We could mandate that all implementation MUST make random
fluctuations to the max frame size to hunt down and shame those
implementers who stupidly think that they need not implement a feature that
they do not need. [ Note that was sarcasm for those who don't get it ]

I think the WINDOW_UPDATE is well motivated to support the known use-cases
where multiplexing is not needed momentarily.     However the proposal
stands on without it and it could be removed if the WG explicitly
acknowledges that they will not support the issue that it is trying to
address (or comes up with an alternative).

But I'd ask the WG to mull on the proposal in total for at a little bit
before we abandon parts of it.

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.