- From: <bugzilla@jessica.w3.org>
- Date: Wed, 31 Aug 2011 23:50:37 +0000
- To: public-webapps@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13984 Summary: Need a way to object detect binary support before connecting Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: w3.org@martintribe.org QAContact: member-webapi-cvs@w3.org CC: mike@w3.org, public-webapps@w3.org The API needs to define a way for Javascript to object detect whether the WebSocket API supports sending and receiving of binary data and this needs to be exposed prior to initiating a connection (e.g. because sub-protocol and extension settings may depend on whether binary data can be sent or not). Chrome 14 and 15 and Firefox 6/7 support the new protocol and other updates to the new API but don't actually support binary data sending/receiving yet. Until the object is instantiated, the WebSocket objects looks the same for the old API as for the new API. I tried the following hack: var wstest = new WebSocket('ws://localhost:57111'); if (typeof(wstest.binaryType) !== "undefined") { ... // binary } else { ... // text only } wstest.close(); wstest = null; However, that is insufficient for a few reasons: - the spec allows for the UA to initiate a connection immediately in the background (e.g. Chrome does this) which means an async error is trigger by failure to connect. - the spec is not crystal clear about what the behavior of binaryType is in the case where binary data is not in fact supported. For example, in Chrome 14 and 15 binaryType is visible and set to "blob" by default and can be set to "arraybuffer". However, binary data is not in fact supported. - it's just plain hideous. My suggestions: - In addition to the readyState constants (CLOSED, CLOSING, etc), the uninstantiated WebSocket object should also have the following constants: BLOB and ARRAYBUFFER which are equal to "blob" and "arraybuffer" respectively. These should only appear in the WebSocket object if those data types are actually supported for sending and receiving. This is backwards compatible with the current definition (i.e. you can do ws.binaryType = "blob"; or ws.binaryType = WebSocket.BLOB); - The spec should clarify that the binaryType field should only appear if binary data is in fact supported (or alternately, it is there but should be empty and throw an error if an attempt is made to set it). -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Wednesday, 31 August 2011 23:50:43 UTC