Re: [websockets] Constructor vs. open()
On Fri, May 27, 2011 at 5:47 PM, Adrian Bateman wrote:
> As I proposed in March [1], we think it makes sense to separate the WebSocket
> constructor from the operation to initiate the network operation. We proposed
> a separate open() method similar to XHR. This allows a WebSocket object to be
> constructed and initialised prior to communication. We think this makes the
> design more future-proof because otherwise and new information required prior
> to establishing the connection will need to be added to the constructor
> arguments.
>
> I'm interested to know how other implementers feel about this proposal.
I do really appreciate the future-proof argument. However, adding
arguments to the constructor can take us pretty far. Something like:
p = {
protocol: "foo",
timeout: 60,
priority: 5,
encryption: {
algo: "AES256",
key: x
}
};
w = new WebSocket(url, p)
is pretty comparable to:
w= new WebSocket();
w.protocol = "foo";
w.timeout = 60;
w.priority = 5;
w.encyption.algo = "AES256";
w.encyption.key = x;
w.open(url);
The main argument against a .open function that I have is that it
forces us to deal with what happens if you call .open multiple times.
It's kind of a pain that XMLHttpRequest allows multiple calls to open
as it adds a lot of implementation complexity for very little user
benefit.
/ Jonas
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
[websockets] Constructor vs. open()
As I proposed in March [1], we think it makes sense to separate the WebSocket constructor from the operation to initiate the network operation. We proposed a separate open() method similar to XHR. This allows a WebSocket object to be constructed and initialised prior to communication. We think this makes the design more future-proof because otherwise and new information required prior to establishing the connection will need to be added to the constructor arguments. I'm interested to know how other implementers feel about this proposal. Thanks, Adrian. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102#c9
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.
[Bug 12102] WebSocket protocol update time
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 Ian 'Hixie' Hickson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #41 from Ian 'Hixie' Hickson 2011-05-27 23:34:39 UTC --- Did all the things I set out in comment 0 except the extensions attribute, which is blocked on an issue in the protocol spec. I'll update that in response to Ian's reply to my mail to him about it. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
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. `._.-(,_..'--(,_..'`-.;.'
[websockets] Binary support changes
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.
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
Israel Hilerio:
> > For the optional parameters variable that is expected by the
> > IDBDatabase.createObjectStore function, would it be possible to constrain
> > the variable to have the keyPath and autoIncrement attributes as part of its
> > instance members and not as part of its inheritance hierarchy?
Jonas Sicking:
> For example we asked that it should not be allowed to implement the
> properties using getters as to avoid having to worry about javascript
> running from inside the createObjectStore implementation, however the
> feedback we got was unanimously strongly opposed that.
One advantage of looking only at own properties is that it would make it
easier if for example you were defining a dictionary type that had
members named "prototype", "toString", etc.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248
There were two options I was considering in the bug. The first was to
test whether the object the property like `"keyPath" in optionsObject`:
keyPathSpecified = optionsObject.[[HasProperty]]("keyPath")
if keyPathSpecified then
keyPath = ToString(optionsObject.[[Get]]("keyPath"))
else
keyPath =
end if
The second is to unconditionally get the property and compare it against
undefined:
keyPath = optionsObject.[[Get]]("keyPath")
if keyPath is undefined then
keyPath =
else
keyPath = ToString(optionsObject.[[Get]]("keyPath"))
end if
Both of these would still find "toString" from the prototype, though.
You could easily define it such that you do only look up own properties,
but as Jonas says some people may think of that as less “JavaScripty”
than the other options.
--
Cameron McCormack ≝ http://mcc.id.au/
[Bug 12433] Define which status code and reason to use in the close frame for close(), when navigating away, and when garbage collecting an open websocket
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12433 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #1 from Ian 'Hixie' Hickson 2011-05-27 20:12:02 UTC --- Done. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
On Fri, May 27, 2011 at 10:27 AM, Israel Hilerio wrote: > For the optional parameters variable that is expected by the > IDBDatabase.createObjectStore function, would it be possible to constrain > the variable to have the keyPath and autoIncrement attributes as part of its > instance members and not as part of its inheritance hierarchy? I think that would not ring well with the ECMAScript people in TC39. For example we asked that it should not be allowed to implement the properties using getters as to avoid having to worry about javascript running from inside the createObjectStore implementation, however the feedback we got was unanimously strongly opposed that. / Jonas
on* attributes on DOM elements
It looks like Gecko, Presto, and Webkit all support on* event attributes on all DOM elements, not just HTMLElement. IE9 seems to only support them on HTMLElement. I would propose that these be supported on all Elements at least for events that are not element-specific (e.g. "click"). -Boris
[indexedDB] OptionalParameter question on IDBDatabase.createObjectStore
For the optional parameters variable that is expected by the IDBDatabase.createObjectStore function, would it be possible to constrain the variable to have the keyPath and autoIncrement attributes as part of its instance members and not as part of its inheritance hierarchy? Israel
Re: [widgets] Widget Updates test case issue: ta-pr-005
On 5/20/11 10:03 AM, Scott Wilson wrote: This test case states: "Tests that update-info element's version attribute should have a value higher than current version for the widget to be updated. The widget is not updated or replaced." However, in the specification itself, there is no condition that the potential update version has to be "higher" than that of the incumbent widget, only different [1]. This is true. Deleted the test case (ta-pr-005.wgt).
