Re: Large Frame Proposal

On 7 Jul 2014, at 9:44 pm, Greg Wilkins <gregw@intalio.com> wrote:

> Mark,
> 
> thanks for the serious consideration.
> 
> I agree that the issues need to be carefully identified.   I think 549,550 and 551 are all good issues to create (although this proposal does not directly address 550).   But I think there should also be issues for 
> 	• a fixed frame size does not allow tuning multiplexing performance based on current/future experience.
> 	• the 16KB frame size is not well tuned for frequent payload sizes
> 	• a fixed frame size cannot be adjusted for specific streams in specific situations that may not required multiplexing efficiency.
> Or at least one issue that the fixed max frame size cannot be tuned for any reason

That's a design decision that was made a long time ago. To reconsider it, I need more than vague concerns that amount to "I don't like it"; I need concrete problems that it causes.


> One note of caution with decomposing to individual issues, is that no single issue may be sufficiently important to rock the boat at this late state, but a proposal that resolves many such issues might well be worth the disruption.

... and that's why I've asked for the WG to take this proposal seriously -- as a potential path to resolving a number of related issues. Strictly speaking, though, it does a lot more than is necessary to get there. 


On 8 Jul 2014, at 8:23 am, Greg Wilkins <gregw@intalio.com> wrote:

> Mark - can you open an issue for this one-   CONTINUATIONS looks like it is only needed for large headers, but it is actually a non optional part of the specification.

That's at most an editorial issue, and probably an invalid one; no where does the spec say you can ignore CONTINUATION, or that it's optional.


Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 8 July 2014 00:59:07 UTC