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

Re: [websockets] Binary support changes

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 27 May 2011 18:18:54 -0700
Message-ID: <BANLkTikZ+_K_PPZvQENwr-=_+k7jZufeWw@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Adrian Bateman <adrianba@microsoft.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
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

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