Re: [websockets] Binary support changes
On Mon, May 30, 2011 at 3:20 AM, Simon Pieters wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12805 > > I agree, using interface object complicates things when working across > globals (you basically need to pass along the global as well which is uglier > than using a string). More than that, basically no authors are even going to understand what's happening here. They'll just use iframes for something and then it will mysteriously fail to work. The cause of failure is pretty much totally incomprehensible unless you're a real JavaScript guru. I ran into this issue a while ago, and it took me a long time to figure out what's going on, despite the fact that I'm vastly more familiar with ECMAScript than 99.9% of web authors and had the help of #whatwg. No API should rely on two different interface objects being equal unless absolutely necessary.
Re: [websockets] Binary support changes
On Sat, 28 May 2011 00:55:03 +0200, 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 but we'd prefer 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. Thanks, Adrian. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12805 I agree, using interface object complicates things when working across globals (you basically need to pass along the global as well which is uglier than using a string). -- Simon Pieters Opera Software
Re: [websockets] Binary support changes
On Fri, May 27, 2011 at 4:29 PM, Ian Hickson 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
RE: [websockets] Binary support changes
On Friday, May 27, 2011 4:30 PM, Ian Hickson wrote:
> On Fri, 27 May 2011, Jonas Sicking wrote:
> > 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.
This seems to add unnecessary complexity both to web developers needing to keep
track of the source global and to the implementation's type system where we
have to go through additional hurdles to get back to the objects in another
context. It might look pretty to use the interface object but a string is just
simpler and not entirely unfamiliar to web developers. For example, canvas
getContext is somewhat similar.
Adrian.
RE: [websockets] Binary support changes
On Friday, May 27, 2011 4:23 PM, Jonas Sicking wrote: > 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). I don't really like this idea. I don't want to have to change the way I read text messages just because I want binary data as a Blob. One of the scenarios are planning for is a text message that contains meta data about subsequent binary messages that will be treated as Blobs. Your proposal would require extra complexity to read text from a Blob or switch back and forth. Adrian.
Re: [websockets] Binary support changes
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. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Binary support changes
On Sat, 28 May 2011, Cameron McCormack wrote: > Ian Hickson: > > 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. > > The difference would just be specifying `"ArrayBuffer"` vs > `ArrayBuffer`, right? Actually XHR uses lowercase strings. > I think the difference in cleanliness is minimal. In JS today, the difference is that mistakes with a string throw an INVALID_STATE_ERR exception while mistakes with the interface objects are more likely to throw a ReferenceError. In other languages, the difference is a compile-time vs run-time error. "Other languages" could include JS compilers, in which case this could be a not trivial win for authors. > Using strings as enumeration values is quite common in JS, but I don’t > think I’ve seen this idiom of using interface objects before. I'm not aware of any other flags that decide what kind of type to return, only responseType and now binaryType. The real question in my mind is why would we use a string when we don't have to? Strings are a terrible interface for enumerations, and an even worse one for types. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Binary support changes
On Fri, May 27, 2011 at 4:02 PM, Ian Hickson 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
Re: [websockets] Binary support changes
Ian Hickson: > 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. The difference would just be specifying `"ArrayBuffer"` vs `ArrayBuffer`, right? I think the difference in cleanliness is minimal. Using strings as enumeration values is quite common in JS, but I don’t think I’ve seen this idiom of using interface objects before. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [websockets] Binary support changes
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
