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

[Douglas Otis <[e-mail]>]

  On 8/14/10 1:03 PM, Scott Ferguson wrote:
> Well, the complexity is more of a spec issue than a coding one because 
> none of these proposals are hugely complicated to implement. 
> (Implementing them efficiently is a different matter.)
>
> A Jamie-style proposal less complex because it leaves the basic frame 
> clean without needing the extension length or the extension payload 
> and without the extra complete-length field. The frame would look like:
>
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+---------+-------------------------------+---------------+
> |I|F|B|opcode(5)| length(16)                    |               |
> |N|I|I|         |                               |               |
> |I|N|G|         |                               |               |
> +-+-+-+---------+-------------------------------+ - - - - - - - +
> | big-length(48) if BIG = 1                                     |
> + - - - - - - - +-----------------------------------------------+
> |               | payload(length)                               |
> +---------------+                                               |
> |                                                               |
> +---------------------------------------------------------------+
>
> As a measure of complexity, compare the features that can vary the 
> frame-header size:
>
>  a) short/long payload length
>  b) extension data
>  c) short/long extension length
>  d) complete message-length
>
> A Jamie-style extension only has the single complexity-feature (a) to 
> the frame-header, while your proposal adds 3 more (b,c,d). Since the 
> Jamie-style extension supports all the extension capabilities that 
> yours does, there's no added capabilities with the extra complexity 
> added by b,c,d.
>
> As a separate issue, your code's signature doesn't capture the essence 
> of the problem, because you really need to consider all the APIs when 
> evaluating a framing proposal, not just one that happens to be easy to 
> implement for the proposal. Your example was a specialized API that 
> really only works for utf-8 encoded 8-bit C-strings.
>
> The basic sender APIs that framing needs to support are:
>
> a)  sendTextMessage(char []buffer, int offset, int length); // 
> JavaScript 16-bit text send
> a*) sendTextMessage(byte []buffer, int offset, int length); // utf-8 
> encoded text (like PHP)
>
> b)  sendBinaryMessage(byte []buffer, int offset, int length); // 
> binary single-buffer send
>
> c)  class BinaryMessageOutputStream {
>    write(byte []buffer, int offset, int length);
>    close();
>  }
>
> d)  class TextMessageWriter {
>    write(char []buffer, int offset, int length);
>    close();
>  }
>
> The receiver variations are
>
> a) char []receiveTextMessage()
>
> b) byte []receiveBinaryMessage() // if returning utf-8 8-bit strings, 
> this is the text receive
>
> c) class BinaryMessageInputStream {
>      int read(byte []buffer, int offset, int length);
>    }
>
> d) class TextMessageReader {
>      int read(char []buffer, int offset, int length);
>    }
>
> A good frame design will support all 5 sender API styles and 4 
> receiver API styles in a straightforward/efficient manner. You can't 
> just pick one API that happens to make a frame proposal work.
>
> -- Scott

This offers a cleaner definition.  The higher level protocol could also 
define an initial frame as a TLV content declaration where the next 
frame (after the TLV) begins the payload.  Perhaps this is what is meant 
by extension?  Having this information in a defined place helps with 
content filtering. Perhaps one of the 5 opcode bits could signal the 
presence of the declaration.

-Doug