Subject: [hybi] how to improve websocket

From: Greg Wilkins <[email-masked]>
Date: Mon, 19 Oct 2009 20:34:04 -0700

http://blogs.webtide.com/gregw/entry/how_to_improve_websocket

cheers

---

From: Joshua Bell <[email-masked]>
Date: Thu, 22 Oct 2009 09:39:37 -0700

> 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...)

---

From: Ian Hickson <[email-masked]>
Date: Fri, 23 Oct 2009 03:59:49 +0000 (UTC)

On Thu, 22 Oct 2009, Joshua Bell wrote:
> 
> * 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. 

No; the only reason for sentinel-based frames was to not rely on authors 
having to determine the length of their UTF-8-encoded strings, which in 
many environments can be easy to get wrong.

> * 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)

The binary frames are in the spec for future extension. Currently 
JavaScript has no binary support so the JS API has no binary support so 
the protocol doesn't expose the binary support. It's specced as it is so 
that when we add such support, new servers won't cause old clients to 
break unexpectedly; they'll just ignore the binary frames.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'