- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 12 Aug 2009 03:06:40 -0700
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 get { "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
Received on Wednesday, 12 August 2009 03:06:40 UTC