- From: Greg Wilkins <gregw@mortbay.com>
- Date: Wed, 12 Aug 2009 12:46:34 +1000
Jonas, Jonas Sicking wrote: > Can you suggest changes to the WS protocol that would make it a better > general-purpose protocol? There were several threads on the IETF HYBI mailing list with some such proposals: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html An example of such a message is at the bottom of this email. However, the response to such proposals was pretty much that they were too complex and not needed for the ws API. It was the result of those interactions that suggested to me that a bidirectional web protocol would be best developed at arms length to the websocket API, and thus the BWTP effort was born. So far the feedback I have received on BWTP is suggesting that it has perhaps gone a little too far the other way and that there are probably some significant simplifications that can be achieved without greatly restricting the feature set. > You've suggested multiplexing, segmentation, > per-frame mime-type and per-frame meta-data so far. Is there anything > else that is needed? It would also be good to know what use cases you > have in mind for all of these features in order to evaluate them. Predicting the future is always hard, but using the present as an indicator is good start. Currently the majority of the web traffic is carried over HTTP which is capable of multiplexing, segmentation, per-frame mime-type and per-frame meta-data. I don't see why adding bidirectional capability should result in any significant reduction in these capabilities of web transports. For example, HTTP can well transport a vast array of content types with meta data support to negotiate accepted languages, types and encodings. The ws API can only handle UTF-8 text datagrams, so as a result the ws protocol has special case handling for UTF-8 text datagrams. So I think that our starting point should be to develop a bidirectional protocol that can well support the current web transport capabilities. I would say that anybody who wishes to advocate a less capable transport should be ask to make the case of why capabilities should be lost with bidirectional protocols. regards Example proposal to improve websocket protocol that was rejected: Greg Wilkins wrote: >> It would be great if the websocket proposal could include >> standard definitions for mime encoded datagrams. >> >> Current frame types are: >> >> 0x00 - sentinel framed UTF-8 message >> 0x80 - length framed binary data. >> >> I'd like to see two additional frame types supported >> by default: >> >> 0x01 - sentinel framed UTF-8 encoded MIME message >> 0x81 - length framed MIME message. >> >> Both these data types would contain a data that commenced >> with a standard mime header (RFC 2045). The header is optional >> and terminated by CR LF CR LF. Thus these types have a minimal >> overhead of 4 bytes. >> >> For both these types, any Content-Length header will be >> ignored and the length indicated by the websocket framing >> minus the header length will be used. >> >> For 0x01 types the content type is assumed to be "text/plain; charset=utf-8" >> If a content type header is specified, it must be "text/????; charset=utf-8" >> >> For 0x81 the content type is assumed to be application/octet-stream unless >> otherwise indicated. >> >> The websocket API would need to be slightly extended to support some >> common types of message. >> >> I would suggest that onmessage always be called for all text >> mime types, but with some additional parameters: eg. >> >> onmessage(text,mimetype,headers) >> >> The browser would be responsible for converting the transported >> charset to the charset of javascript. If the conversion could not >> be done, then the message would be discarded. >> >> Additional events could be supported if you want the browser/server >> to do the parsing for your. For text/xml & text/html: >> >> ondocument(dom,headers) >> >> and for text/json >> >> onobject(object,headers) >> >> >> To send such messages, the API would also need to support >> >> void postMessage(data,headers); >> >> >> >> I think this is a minimal change to websocket and would go a long >> way to address many of the concerns raised here. With the ability >> to send standardized meta data, then the job of coming up with >> standardized multiplexing is much much simpler.
Received on Tuesday, 11 August 2009 19:46:34 UTC