- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Tue, 5 Apr 2011 21:01:27 +0000
- To: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
- CC: Peter Saint-Andre <stpeter@stpeter.im>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Mark Nottingham <mnot@mnot.net>
On Tuesday, April 05, 2011 4:27 AM, Arthur Barstow wrote: > Hi All, > > What needs to be done before the WebSocket API is LC ready? > > Bugzilla has three open bugs for this spec: > > 1. API for send/receive of binary data? Current IETF protocol drafts > have binary type. Consider typed arrays (ArrayBuffer). > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11834 > > 2. WebSocket protocol update time > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 > > 3. The definition of "absolute url" makes https:foo not an absolute url, > since its behavior depends on whether the base is https: or not. Is that > desired? ... > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 We've made some proposals in the 12102 bug based on our prototyping with this API. As we work through this I expect we'll also have feedback on areas we think need additional detail to ensure interoperability by different implementers. I've included our recent feedback below, quoted from the bug. Adrian. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 There are use cases for both Blob and ArrayBuffer. While it's possible to convert between the two it's also convenient to be able to specify the preferred type just like with XHR, which supports both. Supporting both would require a mechanism to specify the preferred type. In fact, as we've been experimenting with the WebSocket API we've found that initiating network I/O from the constructor is somewhat inconvenient. We would much prefer a model more like XHR and feel that this is better for future extensibility as the API develops. Our proposal to start the discussion: * The constructor behavior and signature is changed to follow the XHR model. It instantiates a WebSocket object but does not establish the connection. * A new ready state constant is added to indicate that a WebSocket has been created, but no connection established. * A new open method is added to the API to establish the connection: void open(in DOMString url); * A supportedProtocols attribute is added. This is the list of protocols sent by the client to the server during the handshake. This replaces the protocols parameter in the current constructor. attribute DOMString[] supportedProtocols; * Add overloads to send void send(in Blob data); void send(in ArrayBuffer data); * A binaryResponseType attribute is added to the WebSockets interface which can be set to: "arraybuffer" or "blob". The default string "" might default to ArrayBuffer or it might indicate that the client isn't expecting binary data. We'd like to discuss this more. attribute DOMString binaryResponseType; * Message event event.data returns a string for text messages and the type specified in binaryResponseType for binary data. Message event only fires when the entire message is available.
Received on Tuesday, 5 April 2011 21:01:56 UTC