Re: [websockets] Binary support changes

On Fri, May 27, 2011 at 4:02 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 27 May 2011, Adrian Bateman wrote:
>>
>> I'm pleased to see the changes in the WebSockets API for binary message
>> support. I'm a little confused by this text:
>>
>>     When a WebSocket object is created, its binaryType IDL attribute must
>>     be set to the Blob interface object associated with the same global
>>     object as the WebSocket constructor used to create the WebSocket object.
>>     On getting, it must return the last value it was set to. On setting, if
>>     the new value is either the Blob or ArrayBuffer interface object
>>     associated with the same global object as the WebSocket constructor used
>>     to create the WebSocket object, then set the IDL attribute to this new
>>     value. Otherwise, throw a NOT_SUPPORTED_ERR exception.
>>
>> I don't entirely follow what this is saying
>
> It means you do this:
>
>   mysocket.binaryType = Blob;
>
> ...if you want blobs, and:
>
>   mysocket.binaryType = ArrayBuffer;
>
> ...if you want array buffers.
>
>
>> but we'd prefer
>
> (How do you know what you're prefer if you don't know what it's saying?)
>
>
>> the binaryType to be a DOMString in the same fashion that the
>> responseType is in XHR2. Is there a reason for this to be an object?
>> We'd prefer consistency.
>
> Consistency is good when it makes sense. However, I don't think XHR is a
> good parallel here. XHR has all kinds of additional complexities, for
> example it lets you get a string, whereas here string vs binary is handled
> at the protocol level and so can't ever be confused.
>
> However, if we want consistency here anyway, then I'd suggest we change
> XHR to use the actual type values just like WebSockets. It would IMHO lead
> to much cleaner code.

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;
}

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?

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.


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).

/ Jonas

/ Jonas

Received on Friday, 27 May 2011 23:23:56 UTC