Re: RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]
Yesterday, Hixie checked in a fix for 13777. Bug 13104 (Enable keepalive on WebSocket API) was closed (WontFix) but reopened on September 18. Since various group members agree with not addressing this bug for v1, I will proceed with a CfC to publish a LC of the Web Socket API. (Perhaps this bug could be moved to the PostPoned state and (re-)considered for v2?). Editorial bugs 12510 and 13700 will not block the LC (although it would be great if they were fixed ;-)). If any new bugs are submitted after the RfC begins, we will consider those bugs as LC comments. -AB On 9/15/11 9:07 AM, Arthur Barstow wrote: As an update on this RfC, note that ATM, 13777 is the only non-editorial bug that remains open: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777 I would appreciate it, if people would please provide input on this bug. -AB On 9/9/11 6:05 PM, ext Brian Raymor wrote: 13777 - The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined New, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.
RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]
Hixie, Brian, Jonas, All, Since Brian sent the original e-mail [1], there has been some Bugzilla activity and there are now 5 open bugs for Web Sockets. It appears to me (and please correct me if I'm wrong) the .binaryType issue Jonas raised on the list [2] will not result in any spec changes. I agree 12510 and 13700 are editorial bugs and as such do not need to block LC. Re the other open bugs, Brian suggests: 13104 and 13984 should be closed; 13777 be addressed as outlined in the bug; 13990 (which is now marked as Resolved Invalid) also be addressed as indicated in the bug. Ideally, all open bugs should be closed before a LC is published. However, we can also use an LC now to gather input on the open bugs. Brian proposes an LC be published now with the spec as is. What do others think? -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1365.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html On 9/9/11 6:05 PM, ext Brian Raymor wrote: The IETF HyBi WG has moved beyond Last Call and has presented the WebSockets protocol to the IESG for approval: http://www.ietf.org/mail-archive/web/hybi/current/msg08640.html Now that the protocol is more stable, I think that the current WebSockets API is feature complete and meets the requirements for publishing a Last Call working draft to encourage broader review and feedback. Here is my review of the outstanding bugs (not closed, where resolution not Fixed). I recommend that the outstanding issues be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. 9973 - If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - This bug is a year old, likely out of date now, and from an anonymous contributor 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - This bug is from an anonymous contributor from 6 months ago. The API spec doesn't need to link to server implementations. 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong();//allow client to receive response of ping Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - It's not necessary to include API support for ping/pong. In addition, this bug has been inactive for two months. 13172 - The definition for [MessageEvent] is missing Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - It's been inactive for a month and MessageEvent is defined in the HTML5 Web Messaging specification. 13700 - W3C SotD of this document still mentions whatwg.org version of the WebSocket protocol which is out of date. New, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call 13777 - The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined New, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 13984 - Need a way to object detect which binary formats are supported before connecting New, Assigned to Ian Hickson MICROSOFT PROPOSAL: Close the bug. The original issue (binary support detection in Chrome) should be addressed in WebKit. The additional scenario (querying which binary types are supported) is not required in V1. 13990 - Need a spec for CloseEvent constructor New, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 14057 - In section The WebSocket interface when describing the operation of the WebSocket constructor, the following statement is made: Return a new WebSocket object, and continue these steps in the background (without blocking scripts). ... New, Assigned to Ian Hickson MICROSOFT PROPOSAL: Resolve the bug as duplicate (12510) and close. In addition, there is a new discussion on design changes for binary message support related to the original discussions in 12102 - WebSocket protocol update time: 1-Sep-2011 ; [WebSocket API] .binaryType ; by Jonas, reply by Hixie http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1199.html MICROSOFT PROPOSAL: We do not support the proposed changes. Our implementation experience has not indicated this requirement. We find that most developers use blobs when there is a need to consume data as resources addressed by a URI or to store data in Indexed DB. We have haven't heard of a need to
[websockets] Getting WebSockets API to Last Call
The IETF HyBi WG has moved beyond Last Call and has presented the WebSockets protocol to the IESG for approval: http://www.ietf.org/mail-archive/web/hybi/current/msg08640.html Now that the protocol is more stable, I think that the current WebSockets API is feature complete and meets the requirements for publishing a Last Call working draft to encourage broader review and feedback. Here is my review of the outstanding bugs (not closed, where resolution not Fixed). I recommend that the outstanding issues be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. 9973 - If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - This bug is a year old, likely out of date now, and from an anonymous contributor 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - This bug is from an anonymous contributor from 6 months ago. The API spec doesn't need to link to server implementations. 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong();//allow client to receive response of ping Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - It's not necessary to include API support for ping/pong. In addition, this bug has been inactive for two months. 13172 - The definition for [MessageEvent] is missing Resolved, NeedsInfo MICROSOFT PROPOSAL: Close the bug - It's been inactive for a month and MessageEvent is defined in the HTML5 Web Messaging specification. 13700 - W3C SotD of this document still mentions whatwg.org version of the WebSocket protocol which is out of date. New, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call 13777 - The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined New, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 13984 - Need a way to object detect which binary formats are supported before connecting New, Assigned to Ian Hickson MICROSOFT PROPOSAL: Close the bug. The original issue (binary support detection in Chrome) should be addressed in WebKit. The additional scenario (querying which binary types are supported) is not required in V1. 13990 - Need a spec for CloseEvent constructor New, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 14057 - In section The WebSocket interface when describing the operation of the WebSocket constructor, the following statement is made: Return a new WebSocket object, and continue these steps in the background (without blocking scripts). ... New, Assigned to Ian Hickson MICROSOFT PROPOSAL: Resolve the bug as duplicate (12510) and close. In addition, there is a new discussion on design changes for binary message support related to the original discussions in 12102 - WebSocket protocol update time: 1-Sep-2011 ; [WebSocket API] .binaryType ; by Jonas, reply by Hixie http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1199.html MICROSOFT PROPOSAL: We do not support the proposed changes. Our implementation experience has not indicated this requirement. We find that most developers use blobs when there is a need to consume data as resources addressed by a URI or to store data in Indexed DB. We have haven't heard of a need to send a text message but then treat it as a blob. It also seems simple enough to convert text to blobs upon receipt? While limiting binaryType updates to onopen and onmessage appears to be more deterministic, it also implicitly suggests that network operations are then blocked on the completion of onopen or onmessage. For example, if the goal is to set the binaryType for the next message, then the next message cannot be received and the next onMessage event queued until the current onmessage completes. This may result in performance impacts on implementations that pipeline incoming messages.
Re: [websockets] Getting WebSockets API to Last Call
Regarding the bugs Adrian identified in the e-mail below, here is my take on the status: * Resolved: NeedsInfo: 9973, 12180, 13104; WontFix: 12816, 13178 * Moved to another component: 10213 * Open and considered Editorial (thus will not block LC): 12510, 13162, 13180 and 13172 (not in Adrian's original list) Since Adrian's email, Brian submitted two additional bugs that are Open: 13294 The send() method should fail the WebSocket connection when data cannot be sent http://www.w3.org/Bugs/Public/show_bug.cgi?id=13294 13295 The make disappear a WebSocket object case should not fail the WebSocket connection http://www.w3.org/Bugs/Public/show_bug.cgi?id=13295 Based on the various comments on 12917 (currently Resolved as WontFix), there is no consensus on this bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917. I will follow up separately on 12917 via the [1] thread. Comments, corrections, etc. on the above status are welcome. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0241.html On 7/7/11 6:00 PM, ext Adrian Bateman wrote: We're keen to resolve the remaining issues with the WebSockets API and have a timetable to get to Candidate Recommendation. From informal conversations we've had, we believe other browser vendors share this goal. I think the current WebSocket API is feature complete and meets the requirements for publishing a Last Call working draft to encourage wider review and feedback. There are no tracker issues for WebSockets. Here is my analysis of the outstanding bugs (not closed, where resolution not Fixed). I believe the outstanding issues could be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. 9973 - If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date now, and from an anonymous contributor 10213 - The definition of absolute url makeshttps:foo not an absolute url Open, Assigned to Adam Barth MICROSOFT PROPOSAL: Section 3 of the protocol spec (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address supplied does not match this format. 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months ago MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server implementations 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call 12816 - Make second argument in constructor an object for future extensibility Resolved, WontFix MICROSOFT PROPOSAL: We think the second argument should be an object, not only for future extensibility but to allow binaryType to be set now. 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong(); //allow client to receive response of ping Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We don't think this is necessary. 13162 - The notes really do need to be cleaned up to be made explicit. Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 13180 - [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call.
Re: [websockets] Getting WebSockets API to Last Call
On Mon, Jul 11, 2011 at 11:36 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 11 Jul 2011, Marcos Caceres wrote: On 7/11/11 8:23 PM, Ian Hickson wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. Interesting. How so? Do you have an example where inheriting from EventTarget has become an issue or is going to be an issue? I personally don't have a position on this, I'm just really interested because I had this come up in other (proprietary) contexts. Why is EventTarget special? If one day we decide that many objects should all implement something else, e.g. a Clonable interface or something, what do we do? Then we'll add Clonable as a mixin at that time. Similar to what we'd do if we have some interface that we only want to apply to some HTMLElements (such as all form controls, or all sectioning elements). Adding EventTarget as a base interface is only a bad idea if there appears in the future an interface which is more widely inherited than EventTarget and more widely used than EventTarget. This seems highly unlikely to me given how widely used and inherited EventTarget is. EventTarget is no different from Node. Node supplies the ability to take part in the document tree, EventTarget supplies the ability to receive events. / Jonas
Re: [websockets] Getting WebSockets API to Last Call
On Wed, 13 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:36 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 11 Jul 2011, Marcos Caceres wrote: On 7/11/11 8:23 PM, Ian Hickson wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. Interesting. How so? Do you have an example where inheriting from EventTarget has become an issue or is going to be an issue? I personally don't have a position on this, I'm just really interested because I had this come up in other (proprietary) contexts. Why is EventTarget special? If one day we decide that many objects should all implement something else, e.g. a Clonable interface or something, what do we do? Then we'll add Clonable as a mixin at that time. Similar to what we'd do if we have some interface that we only want to apply to some HTMLElements (such as all form controls, or all sectioning elements). Adding EventTarget as a base interface is only a bad idea if there appears in the future an interface which is more widely inherited than EventTarget and more widely used than EventTarget. This seems highly unlikely to me given how widely used and inherited EventTarget is. EventTarget is no different from Node. Node supplies the ability to take part in the document tree, EventTarget supplies the ability to receive events. So basically the answer to Why is it special is because it is the first interface to have such wide applicability. I don't know if that's convincing. But I can probably live with it, especially since I don't have a good alternative. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Getting WebSockets API to Last Call
On Mon, Jul 11, 2011 at 1:15 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: Can you list the reasons for why you don't think we will not need any of the types listed in the following email: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0732.html I addressed those in the e-mail you replied to earlier: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0237.html This doesn't contain any arguments for why we wouldn't add any of the suggested properties in the future. It just gives solutions for what to do if we do need to add them. However all the suggested solutions create a more complex platform than if we simply make the second argument an object now. We wouldn't add timeout to the constructor because there's no benefit to putting that on the constructor. We wouldn't put priority on the constructor because that would be a per-message feature. You'll likely want a default priority on the socket as to avoid having to specify it on each call. But I guess both timeout and default priority can be set after constructing the WebSocket. However it would be syntactically nice if you can initialize them from the constructor. Oh well, I guess time will tell if we'll end up wanting more constructor arguments. My money is still on that we will. And I had still hoped to hear from other browser vendors. / Jonas
Re: [websockets] Getting WebSockets API to Last Call
On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) It's a judgement call. I think we're just making different judgements on how likely it is that we'll need to extend this in the future. So far I haven't seen any suggestions that would need a change to the constructor. We shouldn't try to solve problems we can't even imagine yet; how could we possibly evaluate our solutions? I'm all for designing for the future; in fact many of the APIs in the specs I edit have future directions already designed and specced out, but just commented out. Here, however, I really don't see why we would expect the constructor to need extensions, especially extensions that would need an object. (I also don't really see what's special about this one in particular that means it should have this but other constructors should not.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Getting WebSockets API to Last Call
On Mon, Jul 11, 2011 at 11:04 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. It's a judgement call. I think we're just making different judgements on how likely it is that we'll need to extend this in the future. So far I haven't seen any suggestions that would need a change to the constructor. We shouldn't try to solve problems we can't even imagine yet; how could we possibly evaluate our solutions? Can you list the reasons for why you don't think we will not need any of the types listed in the following email: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0732.html I'm also still interested in hearing feedback from other implementers. So far only two have spoken up and have both been in favor of making the argument an object. / Jonas
Re: [websockets] Getting WebSockets API to Last Call
On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. It's a judgement call. I think we're just making different judgements on how likely it is that we'll need to extend this in the future. So far I haven't seen any suggestions that would need a change to the constructor. We shouldn't try to solve problems we can't even imagine yet; how could we possibly evaluate our solutions? Can you list the reasons for why you don't think we will not need any of the types listed in the following email: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0732.html I addressed those in the e-mail you replied to earlier: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0237.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Getting WebSockets API to Last Call
On 7/11/11 8:23 PM, Ian Hickson wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. Interesting. How so? Do you have an example where inheriting from EventTarget has become an issue or is going to be an issue? I personally don't have a position on this, I'm just really interested because I had this come up in other (proprietary) contexts. Kind regards, Marcos
Re: [websockets] Getting WebSockets API to Last Call
On 07/11/2011 09:23 PM, Ian Hickson wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. How will that complicate the platform in the future? -Olli It's a judgement call. I think we're just making different judgements on how likely it is that we'll need to extend this in the future. So far I haven't seen any suggestions that would need a change to the constructor. We shouldn't try to solve problems we can't even imagine yet; how could we possibly evaluate our solutions? Can you list the reasons for why you don't think we will not need any of the types listed in the following email: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0732.html I addressed those in the e-mail you replied to earlier: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0237.html
Re: [websockets] Getting WebSockets API to Last Call
On Mon, 11 Jul 2011, Marcos Caceres wrote: On 7/11/11 8:23 PM, Ian Hickson wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. Interesting. How so? Do you have an example where inheriting from EventTarget has become an issue or is going to be an issue? I personally don't have a position on this, I'm just really interested because I had this come up in other (proprietary) contexts. Why is EventTarget special? If one day we decide that many objects should all implement something else, e.g. a Clonable interface or something, what do we do? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Getting WebSockets API to Last Call
On Mon, Jul 11, 2011 at 11:23 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. It's a judgement call. I think we're just making different judgements on how likely it is that we'll need to extend this in the future. So far I haven't seen any suggestions that would need a change to the constructor. We shouldn't try to solve problems we can't even imagine yet; how could we possibly evaluate our solutions? Can you list the reasons for why you don't think we will not need any of the types listed in the following email: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0732.html I addressed those in the e-mail you replied to earlier: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0237.html This doesn't contain any arguments for why we wouldn't add any of the suggested properties in the future. It just gives solutions for what to do if we do need to add them. However all the suggested solutions create a more complex platform than if we simply make the second argument an object now. / Jonas
Re: [websockets] Getting WebSockets API to Last Call
On 7/11/11 8:36 PM, Ian Hickson wrote: On Mon, 11 Jul 2011, Marcos Caceres wrote: On 7/11/11 8:23 PM, Ian Hickson wrote: On Mon, 11 Jul 2011, Jonas Sicking wrote: On Mon, Jul 11, 2011 at 11:04 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 8 Jul 2011, Jonas Sicking wrote: On the other hand, we should [not] do things now that are likely to create a more complicated or inconsistent platform in the future. I agree, indeed that's my main reason for not wanting to make objects inherit from EventTarget. :-) I think adding EventTarget to the chain is a simplification as it makes that interface more consistent with the majority of other ones. I mean in general, on any interface. IMHO nothing should inherit from EventTarget. That some interfaces do in the specs today is a relatively new development and IMHO one that will complicate the platform in the future. Interesting. How so? Do you have an example where inheriting from EventTarget has become an issue or is going to be an issue? I personally don't have a position on this, I'm just really interested because I had this come up in other (proprietary) contexts. Why is EventTarget special? I don't know about special, but some things do lend themselves to having events fired at them (given a good use case, where events are coming from external sources). If one day we decide that many objects should all implement something else, e.g. a Clonable interface or something, what do we do? I agree with what you are saying in general (I have no opinion wrt WebSockets). If there is no valid case right here, right now, then don't try to predict the future. Thanks for taking the time to clarify that for me :)
Re: [websockets] Getting WebSockets API to Last Call
On Mon, 11 Jul 2011, Jonas Sicking wrote: Can you list the reasons for why you don't think we will not need any of the types listed in the following email: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0732.html I addressed those in the e-mail you replied to earlier: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0237.html This doesn't contain any arguments for why we wouldn't add any of the suggested properties in the future. It just gives solutions for what to do if we do need to add them. However all the suggested solutions create a more complex platform than if we simply make the second argument an object now. We wouldn't add timeout to the constructor because there's no benefit to putting that on the constructor. We wouldn't put priority on the constructor because that would be a per-message feature. We wouldn't put encryption in the constructor because that's handled by TLS already. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Getting WebSockets API to Last Call
On Fri, 08 Jul 2011 00:55:11 +0200, Jonas Sicking jo...@sicking.cc wrote: I don't have an opinion on url parsing since I don't know enough about it. However throwing an exception on an invalid URI sounds good to me. I do not think we would want to start throwing on spaces appearing in e.g. the path segment. You only want to throw when the URL cannot be resolved. This requires the still-not-done work on URLs to be done. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Getting WebSockets API to Last Call
On 7/7/11 6:00 PM, ext Adrian Bateman wrote: We're keen to resolve the remaining issues with the WebSockets API and have a timetable to get to Candidate Recommendation. From informal conversations we've had, we believe other browser vendors share this goal. I think the current WebSocket API is feature complete and meets the requirements for publishing a Last Call working draft to encourage wider review and feedback. There are no tracker issues for WebSockets. Here is my analysis of the outstanding bugs (not closed, where resolution not Fixed). I believe the outstanding issues could be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. I think the spirit of the publication process is that all bugs that affect an implementation should be resolved before going to LC. As such, it would be helpful if others would do as Jonas did and provide feedback on the bugs and/or Adrian's general proposal to move to LC as is. If there is consensus within the group to go to LC with these bugs open, we can do so, but it may be preferable to do some extra work now if it can prevent the overhead of additional LCs. 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. The bug only includes comments from IanH and Adrian. It does seem like a mismatch in requirements for deflate-stream to be optional in the protocol and mandatory in the API. What do others think about this bug? -AB
Re: [websockets] Getting WebSockets API to Last Call
On Thu, 7 Jul 2011, Adrian Bateman wrote:
10213 - The definition of absolute url makes https:foo not an absolute url
Open, Assigned to Adam Barth
MICROSOFT PROPOSAL: Section 3 of the protocol spec
(http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3)
shows the
valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if
the address
supplied does not match this format.
This isn't really a WebSocket bug, it's a URL bug. There's just no URL
component. I've moved it to another component.
Having said that, there is a related problem, which is that the hybi
working group has broken the definition of how to parse the urls. I'll
have to update the websockets api accordingly. It's not a major issue
though.
12816 - Make second argument in constructor an object for future extensibility
Resolved, WontFix
MICROSOFT PROPOSAL: We think the second argument should be an object, not
only for future
extensibility but to allow binaryType to be set now.
You can set binaryType now already:
var server = new WebSocket('ws://whatwg.org/database');
server.binaryType = 'arraybuffer';
What's wrong with this?
12917 - deflate-stream should be an optional extension when establishing a
connection
Resolved, WontFix
MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the
protocol spec
on what is optional in the protocol. The API spec should not normatively
mention specific
extensions. References to deflate-stream should be informative and only
provided as examples.
I strongly disagree. We must have interoperability amongst browser user
agents. Having some support compression and others not would lead to
authoring mistakes and will force us into either having or not having
compression based on how big sites first get this wrong.
13104 - 1) ping(msg); //allow client to send server ping as per websocket
spec 2) onpong();
//allow client to receive response of ping
Open, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We don't think this is necessary.
I've closed this one (no use case was specified).
13178 - binaryType should be immutable after connection is established
Open, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.
That makes no sense. The whole point of the feature is to allow authors to
handle incoming data in the most appropriate way for the next packet.
(I've skipped the editorial and pending needsinfo bugs.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Getting WebSockets API to Last Call
On Thu, 7 Jul 2011, Jonas Sicking wrote: 12816 - Make second argument in constructor an object for future extensibility I'd like to see this change made too. So far there's been two counter proposals in the bug for how to deal with future extensions (which I strongly suspect we'll end up having to do in the future): 1. Wait to open the connection until returning to the event loop which delays starting the already slow network handshake. This is especially a problem in Web Workers where returning to the event loop can take a very long time. 2. Make the second argument either be a string, a array of strings, or a object. This is messy both from a user perspective and from an implementation perspective. This really seems to me like a premature optimisation. We shouldn't be fixing problems we don't already have, _especially_ if doing so complicates the platform (as it does here). There are many ways we can extend the feature in the future. Named constructors, overloaded constructors as you suggest, designing features so they don't need to be set before the handshake (binaryType being an example of this), designing the features so that authors don't need to be involved at all, etc. For example, we don't need to put a timeout feature into the constructor, since that's not needed before the handshake is started. We don't need to put priority information into the handshake, since we would likely want to support changing the priority setting during the lifetime of the object, or even on a post-by-post basis. Another feature that was suggested is encryption, and we already support that using TLS in a way that doesn't require author to explicitly set an algorithm, which is in fact likely better from a security perspective. I'm not at all convinced that we are actually going to need to extend the constructor at all, nor that if we ever actually have to extend the constructor that doing so will be problematic. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Getting WebSockets API to Last Call
On Fri, Jul 8, 2011 at 1:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 7 Jul 2011, Jonas Sicking wrote: 12816 - Make second argument in constructor an object for future extensibility I'd like to see this change made too. So far there's been two counter proposals in the bug for how to deal with future extensions (which I strongly suspect we'll end up having to do in the future): 1. Wait to open the connection until returning to the event loop which delays starting the already slow network handshake. This is especially a problem in Web Workers where returning to the event loop can take a very long time. 2. Make the second argument either be a string, a array of strings, or a object. This is messy both from a user perspective and from an implementation perspective. This really seems to me like a premature optimisation. We shouldn't be fixing problems we don't already have, _especially_ if doing so complicates the platform (as it does here). On the other hand, we should do things now that are likely to create a more complicated or inconsistent platform in the future. It's a judgement call. I think we're just making different judgements on how likely it is that we'll need to extend this in the future. / Jonas
[websockets] Getting WebSockets API to Last Call
We're keen to resolve the remaining issues with the WebSockets API and have a timetable to get to Candidate Recommendation. From informal conversations we've had, we believe other browser vendors share this goal. I think the current WebSocket API is feature complete and meets the requirements for publishing a Last Call working draft to encourage wider review and feedback. There are no tracker issues for WebSockets. Here is my analysis of the outstanding bugs (not closed, where resolution not Fixed). I believe the outstanding issues could be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. 9973 - If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date now, and from an anonymous contributor 10213 - The definition of absolute url makes https:foo not an absolute url Open, Assigned to Adam Barth MICROSOFT PROPOSAL: Section 3 of the protocol spec (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address supplied does not match this format. 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months ago MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server implementations 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call 12816 - Make second argument in constructor an object for future extensibility Resolved, WontFix MICROSOFT PROPOSAL: We think the second argument should be an object, not only for future extensibility but to allow binaryType to be set now. 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong(); //allow client to receive response of ping Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We don't think this is necessary. 13162 - The notes really do need to be cleaned up to be made explicit. Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 13180 - [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call.
Re: [websockets] Getting WebSockets API to Last Call
On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman adria...@microsoft.com wrote: We're keen to resolve the remaining issues with the WebSockets API and have a timetable to get to Candidate Recommendation. From informal conversations we've had, we believe other browser vendors share this goal. I think the current WebSocket API is feature complete and meets the requirements for publishing a Last Call working draft to encourage wider review and feedback. There are no tracker issues for WebSockets. Here is my analysis of the outstanding bugs (not closed, where resolution not Fixed). I believe the outstanding issues could be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. Yes, we'd like to see this happen very soon too as we'd like to unprefix our implementation. 9973 - If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date now, and from an anonymous contributor Sounds good. 10213 - The definition of absolute url makes https:foo not an absolute url Open, Assigned to Adam Barth MICROSOFT PROPOSAL: Section 3 of the protocol spec (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address supplied does not match this format. I don't have an opinion on url parsing since I don't know enough about it. However throwing an exception on an invalid URI sounds good to me. 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months ago MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server implementations Agreed. 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call Agreed. 12816 - Make second argument in constructor an object for future extensibility Resolved, WontFix MICROSOFT PROPOSAL: We think the second argument should be an object, not only for future extensibility but to allow binaryType to be set now. I'd like to see this change made too. So far there's been two counter proposals in the bug for how to deal with future extensions (which I strongly suspect we'll end up having to do in the future): 1. Wait to open the connection until returning to the event loop which delays starting the already slow network handshake. This is especially a problem in Web Workers where returning to the event loop can take a very long time. 2. Make the second argument either be a string, a array of strings, or a object. This is messy both from a user perspective and from an implementation perspective. Do any implementations prefer the current specced behavior? Otherwise I'll push for making this change in firefox. 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. I agree with the WONTFIX here. I think optional parts of specifications is a bad thing in the web space and bad for interoperability. If we really end up needing the ability to set optional parts we can always add that in the future. 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong(); //allow client to receive response of ping Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We don't think this is necessary. Agreed. If needed we can always add this in the future. 13162 - The notes really do need to be cleaned up to be made explicit. Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call Agreed. 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. I don't agree with making binaryType immutable, and I added a comment to that effect to the bug. I did also put in another proposal in the bug which also aims to reduce implementation complexity and improve performance. 13180 - [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call. Agreed. / Jonas
RE: [websockets] Getting WebSockets API to Last Call
On Thursday, July 07, 2011 3:55 PM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman adria...@microsoft.com wrote: 12917 - deflate-stream should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to deflate-stream should be informative and only provided as examples. I agree with the WONTFIX here. I think optional parts of specifications is a bad thing in the web space and bad for interoperability. If we really end up needing the ability to set optional parts we can always add that in the future. I agree with the general principle of not adding optional features. However, I think this case is different for a couple of reasons: 1) This is optional in the protocol spec. If you don't think it should be optional in the protocol that argument should be made in the IETF working group. I don't agree that the W3C API should override the discussions in the protocol working group just because some people don't like the outcome. 2) This feature is an extension point. Its sole purpose is to support optional features. Mandating one example of an extension seems arbitrary to me. As soon as there is another extension there will still be differences. We believe that there will be legitimate implementations that don't want to support deflate-stream and servers will have to support with and without to be conforming anyway. 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. I don't agree with making binaryType immutable, and I added a comment to that effect to the bug. I did also put in another proposal in the bug which also aims to reduce implementation complexity and improve performance. Thanks for the feedback on this one. It would be good to get a sense from other implementers about how there feel here. Cheers, Adrian.
