Re: [hybi] Framing take IV

[Greg Wilkins <[e-mail]>]

On 4 August 2010 11:20, Maciej Stachowiak <[e-mail]> wrote:

>
> On Aug 3, 2010, at 6:07 PM, Greg Wilkins wrote:
>
>
>
>
> On 4 August 2010 10:53, Ian Hickson <[e-mail]> wrote:
>
>> On Wed, 4 Aug 2010, Greg Wilkins wrote:
>> >
>> > I think that we have reasonable consensus on something like:
>> >
>> >   +--------------------------------------------------+
>> >   | frag(1) |unused(3) | opcode(4) |  Length(16)     |
>> >   +--------------------------------------------------+
>> >   |                      Data                        |
>> >   +--------------------------------------------------+
>>
>> Why would we have a fixed length field with fragmentation rather than a
>> variable length field?
>>
>> If we can have a variable width length field, do we need to support
>> fragmentation in the first version? I could see an argument for supporting
>> fragmentation in the case of multiplexing, but without that it doesn't
>> seem to actually gain us anything.
>>
>>
> Ian,
>
> at the f2f there was a very loud hum for a single framing mechanism.
> Following that, there were loud hums for fragmentation and fixed length
> frames, even without consideration of multiplexing.
>
> I believe the feeling was that fragmentation makes sending and receiving
> big messages simpler.  It also prepares the ground for multiplexing
> extensions. There was very little support for variable length lengths, as
> that was just seen as more complex than fragmentation.
>
> But if you have a counter proposal that meets the single framing hum, then
> please post it.
>
>
> Hum volume is not an adequate response to a reasoned argument. If people
> think fragmentation is simpler than a variable size length field, they
> should explain why, rather than just citing the number of people who agree.
>
>
I did briefly explain.  I cited the hum volume not as an argument, but as an
indication that we have already had the arguments explained.

happy to explain again in a little bit more detail:

   - variable length length fields is more complex than a fixed length
   length field.
   - sending large content in a single frame is difficult if the content is
   being generated dynamically or it's length is otherwise not known.
   - a small fixed sized length allows simple implementations to have fixed
   sized buffers (eg 64k)
   - fragmentation prepares the ground for future extensions for
   multiplexing and flow control.
   - fragmentation on its own is not that complex


But if you have a counter proposal that you think might satisfy the hummers,
please make it.  The current protocol certainly does not.

cheers