Re: [webkit-dev] Staging WebSocket protocol deployment
I think 3 sounds best. 4 seems reasonable. If we need to go with 1 or 2, we should talk to Mozilla to decide whether to standardize on the x or use our own prefixes. If we go with option 3, I think a WebKit blog post would be a good way to make out intentions for WebSockets clear. On Wed, Nov 18, 2009 at 4:38 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I vote option (3). Even if we keep current protocol stack with prefixed URI, I'm wondering any websocket server implementation will keep compatibility with procotol of our prefixed URI.. Or, if some websocket server implementation keeps compatible with prefixed URI, I believe it's worse situation for future. -- ukai I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Mon, Nov 16, 2009 at 5:45 PM, Alexey Proskuryakov a...@webkit.org wrote: 15.11.2009, в 17:18, Yuzo Fujishima написал: Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. It doesn't seem that wide use is possible before the protocol evolves into something that works with all proxies - or before a heavyweight service forces network administrators to update their proxies for compatibility with the existing protocol. Frankly, I think that the former is more likely. The only case that is likely to work on Internet reliably right now is running over SSL, which negates some of the protocol's strengths - it will no longer be as efficient as it's meant to be. In order to enable port sharing, this also requires one to serve documents over https, which is an additional cost. You're right that WebSocket users will need to use SSL to get around proxy issues, but I don't think it's actually that big of a deal. I know of several sites looking at using them; all are planning on using SSL, and I'm not aware of any being particularly concerned about this. As for the proxy issues themselves: they're not going to go away any time soon. And the longer we label this protocol as experimental, the longer it's going to take for things to move forward. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? In practice, this means half a dozen lines of browser detection code - which does not matter when deploying a technology of this magnitude, as already mentioned in this thread. That's not the matter. The matter is what this signals to people considering using WebSockets. Each UA having their own code typically signals that things are non-standard, which is not true in this case. It seems that a common argument against using a name other than ws is that a scheme is just an opaque identifier, so it doesn't matter which name to use, so we can just change the name later, if necessary. I don't think that this is a strong argument - if the name doesn't matter in the long run (which I wouldn't agree with, but anyway), why sweat about what the name is during experimental rollout of the feature? This argument works both for and against. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Nov 15, 2009, at 3:19 PM, Adam Barth wrote: On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth aba...@webkit.org wrote: Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Here's the timeline for the HyBi WG: http://trac.tools.ietf.org/bof/trac/wiki/HyBi Goals and Milestones: - Mar-2010: WGLC on the Design Space characterization (Informational) May-2010: WGLC on Requirements document on Short term solution Jul-2010: WGLC on Requirements document on Long term solution Nov-2010: Requirements to IESG Mar-2011: WGLC on Short term solution improvements Nov-2011: WGLC on Long term solution protocol I read this as one year for requirements and another year for a protocol assuming the WG stays on schedule. With regards to timeline: I don't think it is sensible to wait for the IETF to get through the full process all the way to an RFC, particularly if that process takes multiple years. After all, we don't do that for features of HTML5 itself. I think it would be reasonable to give WebSocket 6 months or so in some experimental form, and then declare it ready for prime time if no nasty surprises come up, even if the IETF is still wrapped in beaurocracy. I see also that Mozilla is embarking on a WebSocket implementation. Given these considerations, I am leaning towards option (3) from my recent email, which is to use the regular URI schemes and issue a public warning, or option (4) (support both prefixed and unprefixed). Further opinions welcome. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
Hi, Maciej, I vote for (3). Yuzo On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I vote option (3). Even if we keep current protocol stack with prefixed URI, I'm wondering any websocket server implementation will keep compatibility with procotol of our prefixed URI.. Or, if some websocket server implementation keeps compatible with prefixed URI, I believe it's worse situation for future. -- ukai I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
15.11.2009, в 17:18, Yuzo Fujishima написал: Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. It doesn't seem that wide use is possible before the protocol evolves into something that works with all proxies - or before a heavyweight service forces network administrators to update their proxies for compatibility with the existing protocol. Frankly, I think that the former is more likely. The only case that is likely to work on Internet reliably right now is running over SSL, which negates some of the protocol's strengths - it will no longer be as efficient as it's meant to be. In order to enable port sharing, this also requires one to serve documents over https, which is an additional cost. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? In practice, this means half a dozen lines of browser detection code - which does not matter when deploying a technology of this magnitude, as already mentioned in this thread. It seems that a common argument against using a name other than ws is that a scheme is just an opaque identifier, so it doesn't matter which name to use, so we can just change the name later, if necessary. I don't think that this is a strong argument - if the name doesn't matter in the long run (which I wouldn't agree with, but anyway), why sweat about what the name is during experimental rollout of the feature? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth aba...@webkit.org wrote: Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Here's the timeline for the HyBi WG: http://trac.tools.ietf.org/bof/trac/wiki/HyBi Goals and Milestones: - Mar-2010: WGLC on the Design Space characterization (Informational) May-2010: WGLC on Requirements document on Short term solution Jul-2010: WGLC on Requirements document on Long term solution Nov-2010: Requirements to IESG Mar-2011: WGLC on Short term solution improvements Nov-2011: WGLC on Long term solution protocol I read this as one year for requirements and another year for a protocol assuming the WG stays on schedule. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Yuzo On Mon, Nov 16, 2009 at 8:19 AM, Adam Barth aba...@webkit.org wrote: On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth aba...@webkit.org wrote: Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Here's the timeline for the HyBi WG: http://trac.tools.ietf.org/bof/trac/wiki/HyBi Goals and Milestones: - Mar-2010: WGLC on the Design Space characterization (Informational) May-2010: WGLC on Requirements document on Short term solution Jul-2010: WGLC on Requirements document on Long term solution Nov-2010: Requirements to IESG Mar-2011: WGLC on Short term solution improvements Nov-2011: WGLC on Long term solution protocol I read this as one year for requirements and another year for a protocol assuming the WG stays on schedule. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Sun, 15 Nov 2009, Adam Barth wrote: On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth aba...@webkit.org wrote: Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Here's the timeline for the HyBi WG: http://trac.tools.ietf.org/bof/trac/wiki/HyBi Goals and Milestones: - Mar-2010: WGLC on the Design Space characterization (Informational) May-2010: WGLC on Requirements document on Short term solution Jul-2010: WGLC on Requirements document on Long term solution Nov-2010: Requirements to IESG Mar-2011: WGLC on Short term solution improvements Nov-2011: WGLC on Long term solution protocol I read this as one year for requirements and another year for a protocol assuming the WG stays on schedule. Then I guess WebSockets will be a WHATWG spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Jeremy Orlow wrote: I don't buy that at all. There's plenty of features with the webkit- prefix and I think it's pretty clear to developers what that means. IMHO it makes no difference to authors if they have to use webkit-ws: or ws: -- either way, they might come to depend on it, and either way if other browsers want to be compatible with code written for us, they have to use the same value. The features where we have the webkit- prefix are CSS properties and values. There, there's no problem with each browser vendor doing their own extension, since you can list multiple properties. This doesn't apply to URLs like here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Adam Barth wrote: Does the IETF WG have a timeline? The IETF WG doesn't event exist yet. My understanding is that IETF WG take at least a year to do anything. They take as long as we (the community) let them take. As far as I'm concerned, the WebSocket feature is very mature. The IETF is late to this party; WebSocket has been under development since 2005. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Staging WebSocket protocol deployment
While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
*cc'ing others involved in WebSockets (server and client side) I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? I'm not necessarily against this change, just confused by it. * On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov a...@webkit.org wrote: While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
There is the browser side: http://www.w3.org/TR/2009/WD-websockets-20091029/ In that spec, it says This specification is being developed in conjunction with an Internet Draft for a wire protocol, the Web Socket Protocol, available from the IETF at the following location: - WebSocket Protocol Internet-Draft: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol On Fri, Nov 13, 2009 at 10:46 AM, Jeremy Orlow jor...@chromium.org wrote: *cc'ing others involved in WebSockets (server and client side) I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? I'm not necessarily against this change, just confused by it. * On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov a...@webkit.orgwrote: While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
Oops...I missed that. SGTM then. On Fri, Nov 13, 2009 at 11:14 AM, David Levin le...@chromium.org wrote: There is the browser side: http://www.w3.org/TR/2009/WD-websockets-20091029/ In that spec, it says This specification is being developed in conjunction with an Internet Draft for a wire protocol, the Web Socket Protocol, available from the IETF at the following location: - WebSocket Protocol Internet-Draft: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol On Fri, Nov 13, 2009 at 10:46 AM, Jeremy Orlow jor...@chromium.orgwrote: *cc'ing others involved in WebSockets (server and client side) I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? I'm not necessarily against this change, just confused by it. * On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov a...@webkit.orgwrote: While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
This is a great idea. It would be a shame to put this out there and be stuck with a crippling set of design decisions as happened with LocalStorage. In practice, using WebSockets is a big enough change for web developers that adding the webkit- is nothing more than a minor inconvenience (if that) for early adopters. Ojan On Fri, Nov 13, 2009 at 11:14 AM, David Levin le...@chromium.org wrote: There is the browser side: http://www.w3.org/TR/2009/WD-websockets-20091029/ In that spec, it says This specification is being developed in conjunction with an Internet Draft for a wire protocol, the Web Socket Protocol, available from the IETF at the following location: - WebSocket Protocol Internet-Draft: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol On Fri, Nov 13, 2009 at 10:46 AM, Jeremy Orlow jor...@chromium.orgwrote: *cc'ing others involved in WebSockets (server and client side) I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? I'm not necessarily against this change, just confused by it. * On Fri, Nov 13, 2009 at 10:03 AM, Alexey Proskuryakov a...@webkit.orgwrote: While WebSocket API is fairly stable, the discussion of underlying protocol at IETF is far from being done. It could be disruptive to ship our WebSocket implementation in a way that would effectively freeze the protocol. One way to achieve future compatibility is by using a different scheme for WebSocket URLs - e.g. webkit-ws: and webkit-wss: instead of ws: and wss:, respectively. Depending on how protocol standardization goes, we could alias these later, or add a separate standards compliant implementation. I'm going to submit a patch to this effect, but would like to discuss the idea on the list first. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the webkit- prefix. And once that ship sails, there's not much of a point to adding it. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the webkit- prefix. And once that ship sails, there's not much of a point to adding it. On the other hand, as Ojan pointed out, LocalStorage is a perfect example of an API that was thought to be good and stable that became a disaster. Maybe it is best to put it behind a prefix until we have a better understanding of the beast and some real world implementation experience of the complete stack (not just the part in the browser). +1 for AP's plan. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 3:58 PM, Jeremy Orlow jor...@chromium.org wrote: +1 for AP's plan. There's nothing magical about ws and wss. We can change those names later if we change the protocol (just as easily as we can change webkit-ws). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. What's the harm in prefixing the scheme for now? I see harm when we do this sort of thing for every minor feature, but supporting WebSockets isn't just a minor tweak to a web application. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? He's saying if the protocol changes to be incompatible, then it will no longer be ws:, wss: I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the webkit- prefix. And once that ship sails, there's not much of a point to adding it. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Nov 13, 2009, at 4:06 PM, Adam Barth wrote: On Fri, Nov 13, 2009 at 3:58 PM, Jeremy Orlow jor...@chromium.org wrote: +1 for AP's plan. There's nothing magical about ws and wss. We can change those names later if we change the protocol (just as easily as we can change webkit-ws). My impression from the IETF mailing list is as follows: (a) The IETF is likely to charter a Working Group to work on the WebSocket protocol. (b) It will specifically be more or less based on the WebSocket protocol as specified today. (c) There is a lack of consensus about some details (such as whether the baseline should support multiplexing, whether messages should always be length-prefixed and not sentinel-terminated, etc). I don't want to give the likely future IETF WG participants the impression that we're trying to lock in the protocol and pre-empt decisions on potential issues of controversy. I think we (the WebKit community) would really like the WebSocket protocol to succeed, but I don't think we care about some of the fine details enough to try to lock them down or pick a fight with the IETF. I will also add that there are times when rushing to ship features has turned out to be somewhat regrettable in the past. Thus I suggested that we should look into ways to avoid prematurely locking in the protocol. In particular, if the standard changes incompatibly relative to what we ship but there are already sites using the current protocol, I'd like it to be possible for WebKit to support both new-style and old-style sites. Here are some options: (1) For now, ship with webkit-prefixed versions of the URL schemes (if the protocol changes incompatibly, we can make the standard ones use something different; if it doesn't, we can just make it an alias.) This is basically Alexey's proposal. (2) Use the same URL scheme, but rely on some provision for versioning in the WebSocket protocol itself. I don't think there is anything suitable currently. In particular we would need to be able to negotiate the protocol version to use with the site, so both v1 and v2 sites would work. And I don't think there's time to add version negotiation to the spec and implement it before various vendor ship dates. (3) Use ws: or wss: for now, but plan to change the URL scheme in the standard if the protocol does change incompatibly. This assumes buy-in from the specifiers of the protocol I like (1) best, because it's totally future-proof and not presumptuous. I think Ian and Adam Barth are effectively suggesting (3), but I feel like it sends a bad message to assume the eventual IETF Working Group will work around our compatibility needs. Worse yet, they may choose not to do so. Either way, I'd like us to have a plan where we can show we are not trying to pre-empt decisions about the details of the protocol. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 4:01 PM, David Levin le...@google.com wrote: On Fri, Nov 13, 2009 at 3:49 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Nov 13, 2009 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. Sorry I wasn't clear in my word choice. I'm actually on one of the lists, though I obviously don't follow it too closely. :-) The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. Just to be clear, you're saying that it's fairly unlikely that it's going to change in a backwards compatible way? He's saying if the protocol changes to be incompatible, then it will no longer be ws:, wss: Yes, but once a browser ships ws/wss then we're stuck with that version of the protocol. If it starts to catch on, then browsers will need to implement it for a very long time to come. That's what happened with LocalStorage. By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. And I'm not convinced that we'll know whether we're happy until we have some data from real-world use of WebSockets. (Which should start coming in soon after Chrome 4 ships.) I ask because there's not much time left to make such decisions before it goes into Chrome 4 without the webkit- prefix. And once that ship sails, there's not much of a point to adding it. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Jeremy Orlow wrote: By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. Not really. It just means that we might end up stuck with webkit-ws: instead of ws:. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
I don't buy that at all. There's plenty of features with the webkit- prefix and I think it's pretty clear to developers what that means. On Fri, Nov 13, 2009 at 5:43 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. Not really. It just means that we might end up stuck with webkit-ws: instead of ws:. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, Nov 13, 2009 at 5:43 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Nov 2009, Jeremy Orlow wrote: By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. Not really. It just means that we might end up stuck with webkit-ws: instead of ws:. Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Even the timeline for the cookie WG is a year, and we're just speccing widely implemented behavior. I don't think we want to be stuck with webkit-ws forever. Another possibility is x-ws, implying that it's experimental. Honestly, if IETF going to break the protocol, they might as well use a new scheme, like websocket or hybi. This discussion reminds me of http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
