Re: [hybi] Framing proposal with start/end demarcation

[Greg Wilkins <[e-mail]>]

Ian,

I agree that the current protocol can be extended with new frame types
and achieve the desired no-impact-on intermediaries.

It has been one of the options that I've continually listed, but there
is an issue of the "we" in the mechanism for how it is extended.
Currently there is no mechanism to avoid collisions between new
op-codes other than centrally managing them.

Perhaps that is OK and we will agree than centrally managed op-code
allocation is the preferred extension mechanism.

Alternately we could define an opcode negotiation mechanism, which
would have no impact on the framing, but overcome the central managed
issue.

Another option is to have a pre-allocated mime-frame opcode so that
extensions could use that frame type - again that would have no impact
on the actual framing proposed and code+length+data framing is
sufficient (give or take a debate about how length is encoded).

However, there are others that are concerned that those proposals do
not allow sufficient extended data to be associated with data frames,
as might be needed for some extension (although I think the
mime-frame does allow extended data per frame).   So there are some
proposals about how to have optional extension data in every frame.

So we need to stop bickering about if other peoples use-cases are
valid or not, and start expanding on how our preferred framing
mechanisms can actually address all (or most) of the concerns of all
(or most) that have expressed them.

regards

















On 9 August 2010 18:38, Ian Hickson <[e-mail]> wrote:
> On Mon, 9 Aug 2010, Greg Wilkins wrote:
>>
>> I strongly believe that at this stage we need to define an extension
>> mechanism that works with (or is part of ) the websocket framing
>> mechanism, that has reasonable clear support for several types of
>> extensions that could reasonably be anticipated might possibly be
>> supported by protocol extensions in the future.  A primary requirement
>> of this extension mechanism should be that it will not needlessly break
>> intermediaries and infrastructure that has been made websocket aware.
>
> The spec as written now does this. We can add any amount of additional
> data into the frame payload itself and the intermediaries wouldn't be
> affected.
>
> For example, we could add a new kind of frame that is binary data by just
> minting a new frame type and saying that the payload is binary. We could
> add multiplexing by (as a simple example) saying that the first byte of
> any payload is a channel if the client and server agree to multiplex. We
> could add a new frame type that consists of a frame MIME type followed by
> a filename followed by binary data by having the MIME type and filename be
> the first few bytes of the payload, each terminated by a NULL byte or
> prefixed by the number of bytes they take within the payload. We could do
> fragmentation by using new frame types, or by having metadata regarding
> the fragments be the leading or trailing byte(s) of the payload, as agreed
> by the client and server during the handshake.
>
> I can't think of anything we _can't_ do with the current mechanism that
> would impact intermediaries that only support the initial version of the
> protocol, other than move away from message-based communication (and back
> to streaming like TCP).
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>