W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

RE: [websockets] What needs to be done before the spec is LC ready?

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>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB3D2EFA24@TK5EX14MBXC136.redmond.corp.microsoft.com>
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.


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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:31 UTC