Re: [hybi] Framing Take VI (a compromise proposal)

[Patrick McManus <[e-mail]>]

On Mon, 2010-08-16 at 11:00 -0400, John Tamplin wrote:


> If you are already reallocating/copying the buffer it seems like you
> are getting little benefit from getting it after the first frame. 

a couple significant benefits to having TML at some early chunk vs not
having it at all:

* progress indicators
* abort early if tml is too large
* your next realloc() can be your last.

of course, tml in chunk 1 is optimal.

>  It also isn't clear when dynamically generated content is going to be
> known ahead of time.  

my point exactly! CPU and network speed mismatches create large
buffering all the time, and a write-once stream API isn't the only way
applications manage those buffers.

> I would expect a typical implementation 

but not an optimal implementation. The spec shouldn't restrict an
optimal implementation. A typical implementation could just send in
chunk 1 or not at all and the recvr could just ignore it if not in chunk
1. There is no requirement to send or use it at all.

> The main problem with moving it to per-frame extension data is that we
> have to define that extension data now if we want to have TML in the
> base protocol 

I have a different take. Defining a simple non controversial extension
up front is a very good way to get clients and servers implementing code
that handles the extension framework instead of having them just punt on
the topic all together as a quagmire. 

This has to be the simplest possible extension.