[whatwg] BWTP for WebSocket transfer protocol

Jonas Sicking jonas at sicking.cc
Wed Aug 12 03:06:40 PDT 2009

Missed a few parts to reply to:

On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkins<gregw at mortbay.com> wrote:
> Of course the 0x80 length framed binary data type could be
> used to send mime encoded messages, but then there would need
> to be other standards to work out what style of meta-data was
> used - if at all.

We'll need standards on top of BWTP/WS anyway, just getting a JSON
object doesn't really describe what to do with it. I.e. say that you

{ "message": "hello world", "from": "Eric" }

what do you do? Do you append "Eric: hello world" to your IM
conversation? Reject the message because it doesn't contain a
"channel" property which your irc application requires?

> But from a protocol point of view, I simply do not like the
> favoured-son status given to UTF-8 messages.  What good is
> knowing the character encoding if you don't know if the content
> is XML or JSON?  Are we going to have to write sniffers to
> look for XML, JSON, HTML content?
> Why is utf-8 given it's own framing type (sentinels), when
> the length framed binary framing is capable of carry the
> messages just as efficiently and the sentinel framing fails
> to support common transports such as gzipping etc.
> I really think that the ws protocol started from some
> assumptions that are just too special case for the javascript
> API usage and that it will be easier to come up with new
> clean protocols rather than push websocket protocol away
> from the assumptions that underlay is basic design.

While I agree that the protocol should be useful not just to be useful
for a single API, I do think we should keep APIs for using the
protocol in mind when designing it. From that point of view it makes
sense to me to separate text data from binary data. Not just for the
javascript API, but for other APIs as well.

/ Jonas

More information about the whatwg mailing list