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

Re: [websockets] Binary support changes

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 27 May 2011 23:29:48 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>
cc: Adrian Bateman <adrianba@microsoft.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1105272324460.26539@ps20323.dreamhostps.com>
On Fri, 27 May 2011, Jonas Sicking wrote:
> 
> I agree that the WebSocket solution looks cleaner in the simple cases. 
> However it introduces complexity for the case when the script is dealing 
> with multiple globals. For example, what is an implementation supposed 
> to do if a page does:
> 
> ws.binaryType = otherwindow.ArrayBuffer
> 
> or
> 
> otherwindow.useThis(ws);
> with other window containing
> function useThis(ws) {
>   ws.binaryType = Blob;
> }

The spec actually defines this (it throws unless it's the same Window's 
as the WebSocket object's, currently).

What I would really like to use is an actual type type, but JS doesn't 
have those.


> Additionally, how will webpage code check if a websocket connection is 
> currently set to using blobs or arraybuffers if it needs to deal with 
> the case that the connection is potentially coming from another global?

Currently, it needs to use the source global's interface objects.


> Another further complicating matter is that i'm not sure if we can 
> change XHR.responseType given that it unfortunately already has shipped 
> unprefixed in webkit.

Wow, that was quick.


> However, I think there might be another solution to this whole 
> situation. There really is no reason that only binary data can be 
> received as a Blob. Getting data as a Blob is useful any time you're 
> dealing with a large chunk of data where you're not immediately going to 
> process all (or even any) of the data. Hence it would make sense to 
> allow also text data to be received in the form of a Blob.
> 
> So maybe a better solution is to simply add a boolean flag which 
> indicate if data should be received in a "plain" format (strings for 
> textual data, ArrayBuffer for binary), or as a Blob (which would have 
> its .type set to "text/plain;charset=utf8" or "" depending on if it's 
> textual or binary).

How would you write the code for this?

Generally you don't know what you want to do with a WebSocket message 
until at the earliest the point at which you are handling the message 
before. With just binary messages being Blobs, one can imagine a world 
where you receive text messages and immediately decide what to do for the 
next message. In a world where the text messages might also go into blobs, 
aren't we likely to end up seeing people miss a message and end up with 
all their messages going to blobs and never getting out of it? It seems 
rather brittle.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 27 May 2011 23:30:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT