Re: [hybi] how to improve websocket

[Joshua Bell <[e-mail]>]

On Mon, Oct 19, 2009 at 8:34 PM, Greg Wilkins <[e-mail]> wrote:

>
> http://blogs.webtide.com/gregw/entry/how_to_improve_websocket
>
>
I agree with nearly all of of the critiques contained in that analysis. I do
think it would be *possible* to defer the orderly close, message
fragmentation/multiplexing, and extensibility suggestions and still produce
a clearly understandable spec, but believe the rest is fundamental -
specification style (as ABNF), simplified framing (see below), and semantic
specification.

In addition:

* I seem to recall that one of the desires for sentinel-based frames was to
allow octet streams for which the length was not known in advance. For
example, streaming byte-oriented data from an input or other interface
device, and not wanting to use a whole frame for each octet, nor wait until
a certain amount of data had been buffered. That said, only UTF-8 (i.e.
character-based) data is transmissible via the sentinel (without a separate
encoding layer) per section 4.2, which limits the utility

* My reading of section 4.2 (supported by the non-normative section 1.2) in
draft-hixie-thewebsocketprotocol-50 is such that length-based binary data
(frame types 0x80-0xff) are actually deprecated(?) - "6.  Read /length/
bytes." "7.  Discard the read bytes." - the data is never actually to be
interpreted by the client! (Contrast step 5 in the sentinel frame section of
the algorithm, which explicitly calls out when to indicate a message is
received or discarded)

Is this intentional, or an error in the WebSockets Protocol draft? Is this
intentionally deprecated? (i.e. are there implementations which implement
this such that the behavior must be reserved but is not advocated?)

Assuming my reading is not mistaken, the result is confusing; efficient
length-based transmission - which would be most applicable for sending
chunks of data such as text (e.g. JSON-encoded data structures) - is not
supported, yet sentinel-based transmission - most applicable for raw octet
streams of unknown length - is supported but only when constrained to
character-based transmission (as UTF-8 sequences).

So... am I confused? (probably...)