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

[John Tamplin <[e-mail]>]

On Tue, Aug 17, 2010 at 7:50 PM, Thomson, Martin
<[e-mail]>wrote:

>  That wasn’t the suggestion at all.  Binary/text was included.  The
> proposal was length + opcode.  Two opcodes only…for now.
>
>
>
> The other stuff (fragmentation, channels, etc) are well enough understood
> now to say that they can be built in later. Hence, we reserve the bits and
> plan to build them later (or not at all).
>

I think we do know that we have a use-case for fragmentation, as it has been
accepted as a requirement for this protocol.  As previously mentioned, the
inclusion of a total message length was required to remove objections to
fragmentation.  So, other than having two options for the frame length to
preserve efficient encoding of small messages, I think the current proposal
is about as minimal as it can get.

I think if we leave out fragmentation and planned extensibility from the
base protocol, we haven't really accomplished anything and we will either
wind up having to make incompatible changes later or having suboptimal
framing once we do define some extensions.

Let's say we did strip out fragmentation, and even defined the INI/FIN bits
as proposed, but required that they be 1 in the initial version.  Then, any
intermediaries and receivers that are written now will break when
fragmentation is added later, and experience shows that those intermediaries
will be very slowly upgraded.  I think that would add years to when
fragmentation could usefully be used, so I think it is entirely appropriate
that fragmentation support be in the base protocol.

-- 
John A. Tamplin
Software Engineer (GWT), Google