Re: [hybi] WS framing alternative

["Thomson, Martin" <[e-mail]>]

Hi Ian,

> -----Original Message-----
> From: Ian Hickson [mailto:[e-mail]]
> Sent: Tuesday, 27 October 2009 8:12 PM
> To: Thomson, Martin
> Cc: [e-mail]
> Subject: Re: [hybi] WS framing alternative
> 
> On Tue, 27 Oct 2009, Thomson, Martin wrote:
> >
> > WS is binary.
> 
> WS is really a text/binary hybrid. 

...which is even worse.  A hybrid loses the benefits of either approach.  But I tend to think of WS as a purely binary protocol that occasionally looks like text (the header) and can only have textual payloads (frame bodies).  That's consistent with its description.

> > There would be little cost in a minor change that would also enable
> use
> > of MIME.
>
> This would have some pretty major costs:
> 
> - It requires length delimiting for text frames, which is more
> complicated
> to implement (it's non-trivial to tell the difference between
> characters
> and bytes).

I agree with Greg on this point.  Sentinel-based delimiting has its own complexity costs.  Either position has been presented in the rhetoric as better or worse depending on what you value most.

> - It requires parsing using a presized buffer for variable-encoding
> text,
> which risks character/byte mismatches and thus buffer overruns.

That's untrue.  

Or you've made an assumption about my proposal that I never stated: i.e. that length is stated in characters.  Which would, of course, lead to these conclusions.  My intent (which I incorrectly assumed would be clear) was that length was octets.  It seems obvious to me - character encoding changes with different content types, thus you can't use character-based encodings.

> - It allows arbitrary extensions, which introduces an implementation,
> QA,
> documentation, and tutorial cost without providing any new features at
> the
> API level.

Yes, arbitrary extensions have a cost, but I believe that we've benefitted from others having the wherewithal to pay that price before.

Besides, there are two mitigating factors:

 - When interoperating between vendors you cannot guarantee that the opposite end supports an extension, therefore you have to be prepared for them to ignore it.  Therefore, there is no reason that an implementation couldn't do as I suggested and ignore ALL extensions.

 - When not interoperating (the standard web sockets use case of JS talking to the same server), if there's no benefit gained from having extensions, then they can again be ignored.

> - It makes it possible for the headers to have errors in them, which
> requires us to define how to handle errors, and requires significantly
> more code to implement the parsing.

Only if you require syntax checking of the headers.  If you allow for simple ignoring of headers, then it's straight back to the original.

> I disagree that it's minimal.

Excellent.  Then we all disagree ;)

> > Rather than sending:
> >
> >   [0x80, 0x0d]Hello, World!
> 
> Currently you would send a text frame thus:
> 
>    [0x00] Hello, World! [0xFF]

Sure.  See below.

> >   4+
> >
> >   Hell
> >   9
> >
> >   o, World!
> 
> That seems like orders of magnitude more complexity than necessary,
> especially given that the only tangible benefit is a modicum of
> improvement in ease of debugging.

That's why I'm not particularly wed to the idea.  Just like I'm not sold on the benefits of being able to start sending data without knowing its length beforehand.  That's complexity without benefit as far as I can tell.

It's hardly orders of magnitude of complexity, though.  Don't wear out your superlatives.

--Martin