Re: [websockets] Binary support changes

On Fri, May 27, 2011 at 4:29 PM, Ian Hickson <ian@hixie.ch> wrote:
> 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).

So as a function which could possibly be called across scopes, how do
you figure out which scope to grab so that you can grab the interface
objects from there?

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

And how do you find the source's 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.
>
> Wow, that was quick.

I know :(

>> 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?

The same way you would with the .binaryType property you added.

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

Why couldn't this problem occur with binary messages too?

I don't really understand the code pattern you are worried about
people will write that will cause them to get locked into getting
blobs forever. Can you provide an example?

/ Jonas

Received on Saturday, 28 May 2011 01:19:51 UTC