Re: [webkit-dev] bugs.webkit.org UI housekeeping
Hopefully not too off-topic, but along lines of bugs UI housekeeping... I'd like a way to CC myself on a bug without spamming everyone on the bug. Some other bug trackers offer a checkbox that can disable email update. Would anyone else find something like that useful? -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Public APIs for accessing the Javascript debugger
Hi,I'm interested in providing a public C API for accessing debugger functionality in _javascript_Core. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public _javascript_Core APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system.So, is there a reason for there not being a publically accessible debugger API?Alli ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Implementing new WebSocket protocol
Hello, I would like to propose to start implementing the new WebSocket protocol which is discussed in IETF HyBi working group. Protocol draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09 JavaScript API draft: http://dev.w3.org/html5/websockets/ The new protocol is *incompatible* with the old one we are currently supporting. New additions include: - Binary frame support (Blob / ArrayBuffer) - Frame content masking (to solve security concern raised for the old draft) - Protocol extensions (such as frame compression) Because of the incompatibility, existing services using WebSockets are going to break. However, I think this is a necessary cost we have to pay eventually, because: - Other browsers are going to support the new protocol. (Firefox Aurora already includes support for the new protocol.) - The earlier we switch the protocols, the smaller shock there will be. Safari and Chrome are the only browsers that support WebSocket (the old protocol) by default. - There is a security concern raised for the protocol we are currently supporting. * How to proceed My original plan was to implement the new protocol directly (i.e. replacing the old implementation in-place). However Alexey (ap) objected to dropping support for the old protocol immediately. So, I'm currently planning to add a runtime flag to switch the WebSocket protocols used by a WebCore's WebSocket implementation. Other possibilities are to add a compile-time flag or to use (subversion's) branch, which are discussed at: https://bugs.webkit.org/show_bug.cgi?id=60348 The discussion in this bug has been stalled for a while, but I really would like to move forward. Comments and suggestions are greatly appreciated. Regards, Yuta ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Qt build slaves are offline
Dear WebKit developers, unfortunately we had network problems and it made Qt buildbots offline for half a day. And some of them are still broken. Sorry for the inconvenience, and please be patient until fix. After network fixed three of our slaves can't reconnect to the master. We tried to stop and start slaves again and again, but it didn't help. Estabilishing of the TCP connection works, but we always get the following strange twisted exception from the master: twisted.spread.pb.CopyableFailure traceback Traceback unavailable Calling Stale Broker unsafeTracebacks twisted.spread.pb.ProtocolError exceptions.Exception exceptions.BaseException __builtin__.object$.twisted.spread.pb.DeadReferenceError type$.twisted.spread.pb.DeadReferenceError Adam, Bill, could you check it, please? Is it possible that restarting the buildbot master will help us? Thanks in advance, Ossy University of Szeged ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugs.webkit.org UI housekeeping
14.06.2011, в 01:55, Tony Gentilcore написал(а): I'd like a way to CC myself on a bug without spamming everyone on the bug. Some other bug trackers offer a checkbox that can disable email update. Would anyone else find something like that useful? The e-mail notification for CC field changes is (among others) configurable in everyone's Bugzilla preferences. By default, only bug originator and assignee get an e-mail for that. I think that originators generally appreciate any kind of activity on their bugs, even as small as someone adding themselves to the CC list. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Public APIs for accessing the Javascript debugger
The current debugging mechanism is not particularly pleasant to use, nor is it very future proof, it has significant performance costs, and it requires the user to have significant knowledge of the inner workings of JSC. Before we started considering exposing JS debugging through API (and therefore introducing additional binary compatibility requirements) we would need to have an improved debugging mechanism that resolved these issues. --Oliver On Jun 14, 2011, at 7:38 AM, demallien wrote: Hi, I'm interested in providing a public C API for accessing debugger functionality in JavascriptCore. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public JavascriptCore APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system. So, is there a reason for there not being a publically accessible debugger API? Alli ___ 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] Public APIs for accessing the Javascript debugger
Is that an official response?On 14 Jun, 2011,at 06:03 PM, Oliver Hunt oli...@apple.com wrote:The current debugging mechanism is not particularly pleasant to use, nor is it very future proof, it has significant performance costs, and it requires the user to have significant knowledge of the inner workings of JSC. Before we started considering exposing JS debugging through API (and therefore introducing additional binary compatibility requirements) we would need to have an improved debugging mechanism that resolved these issues. --Oliver On Jun 14, 2011, at 7:38 AM, demallien wrote: Hi, I'm interested in providing a public C API for accessing debugger functionality in _javascript_Core. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public _javascript_Core APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system. So, is there a reason for there not being a publically accessible debugger API? Alli ___ 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] Public APIs for accessing the Javascript debugger
It depends on what you mean by official I would probably r- any patch that attempted to create such an API, but it's conceivable that a sensible API could be made that masked the current craziness sufficiently to allow the craziness to be removed later. But any API would need to be very carefully thought out, and would probably require multiple iterations to get to the point where we'd consider the API sufficiently good. --Oliver On Jun 14, 2011, at 9:12 AM, demallien wrote: Is that an official response? On 14 Jun, 2011,at 06:03 PM, Oliver Hunt oli...@apple.com wrote: The current debugging mechanism is not particularly pleasant to use, nor is it very future proof, it has significant performance costs, and it requires the user to have significant knowledge of the inner workings of JSC. Before we started considering exposing JS debugging through API (and therefore introducing additional binary compatibility requirements) we would need to have an improved debugging mechanism that resolved these issues. --Oliver On Jun 14, 2011, at 7:38 AM, demallien wrote: Hi, I'm interested in providing a public C API for accessing debugger functionality in JavascriptCore. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public JavascriptCore APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system. So, is there a reason for there not being a publically accessible debugger API? Alli ___ 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] Public APIs for accessing the Javascript debugger
WebKit-Dev Development webkit-dev@lists.webkit.orgOn 14 Jun, 2011,at 06:30 PM, demallien demall...@mac.com wrote:Yup, that sounds pretty "official" to me :)In which case, are there any plans to start this process? _javascript_Core has been around for quite a while now, and this is a relatively important piece of technology to have for a development environment. Certainly, it is a definite pain point for me to not have this API publicly available - it makes it just that much harder for me to support users of my _javascript_ framework, I'm going to have to supply them with a specially patched version of webkit, which is something that I really didn't want to have to do...AlliOn 14 Jun, 2011,at 06:21 PM, Oliver Hunt oli...@apple.com wrote:It depends on what you mean by "official"I would probably r- any patch that attempted to create such an API, but it's conceivable that a sensible API could be made that masked the current craziness sufficiently to allow the craziness to be removed later. But any API would need to be very carefully thought out, and would probably require multiple iterations to get to the point where we'd consider the API sufficiently good.--OliverOn Jun 14, 2011, at 9:12 AM, demallien wrote:Is that an official response?On 14 Jun, 2011,at 06:03 PM, Oliver Hunt oli...@apple.com wrote:The current debugging mechanism is not particularly pleasant to use, nor is it very future proof, it has significant performance costs, and it requires the user to have significant knowledge of the inner workings of JSC. Before we started considering exposing JS debugging through API (and therefore introducing additional binary compatibility requirements) we would need to have an improved debugging mechanism that resolved these issues. --Oliver On Jun 14, 2011, at 7:38 AM, demallien wrote: Hi, I'm interested in providing a public C API for accessing debugger functionality in _javascript_Core. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public _javascript_Core APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system. So, is there a reason for there not being a publically accessible debugger API? Alli ___ 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] Implementing new WebSocket protocol
I think it's important to move forward with the new protocol. I'm not sure it matter too much what the transition plan is, but we should eventually remove the implementation of the old protocol from WebKit. No one else is going to implement the old protocol. Adam On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura yu...@chromium.org wrote: Hello, I would like to propose to start implementing the new WebSocket protocol which is discussed in IETF HyBi working group. Protocol draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09 JavaScript API draft: http://dev.w3.org/html5/websockets/ The new protocol is incompatible with the old one we are currently supporting. New additions include: - Binary frame support (Blob / ArrayBuffer) - Frame content masking (to solve security concern raised for the old draft) - Protocol extensions (such as frame compression) Because of the incompatibility, existing services using WebSockets are going to break. However, I think this is a necessary cost we have to pay eventually, because: - Other browsers are going to support the new protocol. (Firefox Aurora already includes support for the new protocol.) - The earlier we switch the protocols, the smaller shock there will be. Safari and Chrome are the only browsers that support WebSocket (the old protocol) by default. - There is a security concern raised for the protocol we are currently supporting. * How to proceed My original plan was to implement the new protocol directly (i.e. replacing the old implementation in-place). However Alexey (ap) objected to dropping support for the old protocol immediately. So, I'm currently planning to add a runtime flag to switch the WebSocket protocols used by a WebCore's WebSocket implementation. Other possibilities are to add a compile-time flag or to use (subversion's) branch, which are discussed at: https://bugs.webkit.org/show_bug.cgi?id=60348 The discussion in this bug has been stalled for a while, but I really would like to move forward. Comments and suggestions are greatly appreciated. Regards, Yuta ___ 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] Public APIs for accessing the Javascript debugger
demallien, My sense from Oliver's response is that there aren't any plans to start this process. He's one of the key decision makers on this topic and he sounds pretty negative about creating such an API. Generally, the WebKit project tries to be careful about creating public APIs because they constrain future development of the engine (because we strive for API compatibility). Although JavaScriptCore as a whole has been around for quite a while, the debugging capability is relatively new. Maintaining a specially patched version of WebKit can be a lot of work, so I can certainly understand your reluctance. I wish you the best of luck. Adam On Tue, Jun 14, 2011 at 9:32 AM, demallien demall...@me.com wrote: WebKit-Dev Development webkit-dev@lists.webkit.org On 14 Jun, 2011,at 06:30 PM, demallien demall...@mac.com wrote: Yup, that sounds pretty official to me :) In which case, are there any plans to start this process? JavascriptCore has been around for quite a while now, and this is a relatively important piece of technology to have for a development environment. Certainly, it is a definite pain point for me to not have this API publicly available - it makes it just that much harder for me to support users of my Javascript framework, I'm going to have to supply them with a specially patched version of webkit, which is something that I really didn't want to have to do... Alli On 14 Jun, 2011,at 06:21 PM, Oliver Hunt oli...@apple.com wrote: It depends on what you mean by official I would probably r- any patch that attempted to create such an API, but it's conceivable that a sensible API could be made that masked the current craziness sufficiently to allow the craziness to be removed later. But any API would need to be very carefully thought out, and would probably require multiple iterations to get to the point where we'd consider the API sufficiently good. --Oliver On Jun 14, 2011, at 9:12 AM, demallien wrote: Is that an official response? On 14 Jun, 2011,at 06:03 PM, Oliver Hunt oli...@apple.com wrote: The current debugging mechanism is not particularly pleasant to use, nor is it very future proof, it has significant performance costs, and it requires the user to have significant knowledge of the inner workings of JSC. Before we started considering exposing JS debugging through API (and therefore introducing additional binary compatibility requirements) we would need to have an improved debugging mechanism that resolved these issues. --Oliver On Jun 14, 2011, at 7:38 AM, demallien wrote: Hi, I'm interested in providing a public C API for accessing debugger functionality in JavascriptCore. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public JavascriptCore APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system. So, is there a reason for there not being a publically accessible debugger API? Alli ___ 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] Implementing new WebSocket protocol
On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura yu...@chromium.org wrote: My original plan was to implement the new protocol directly (i.e. replacing the old implementation in-place). However Alexey (ap) objected to dropping support for the old protocol immediately. So, I'm currently planning to add a runtime flag to switch the WebSocket protocols used by a WebCore's WebSocket implementation. Other possibilities are to add a compile-time flag or to use (subversion's) branch, which are discussed at: https://bugs.webkit.org/show_bug.cgi?id=60348 A runtime flag or compile-time flag sound good to me. Ideally, we can re-use the existing infrastructure for old WebSocket to implement new one. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing new WebSocket protocol
We also said previously that we would remove the old protocol due to security concerns about poisoning caches/proxies. We justified not immediately disabling -00 like other browsers did by saying that a new version addressing the issue would come soon. We've had 9 new versions since and have yet to update, which is not good. Microsoft and Mozilla both are targeting newer drafts. Also, the protocol is in last call, and we're now at the point of just making editorial changes. It's stable, and it's time to update the implementation. On Tue, Jun 14, 2011 at 9:49 AM, Adam Barth aba...@webkit.org wrote: I think it's important to move forward with the new protocol. I'm not sure it matter too much what the transition plan is, but we should eventually remove the implementation of the old protocol from WebKit. No one else is going to implement the old protocol. Adam On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura yu...@chromium.org wrote: Hello, I would like to propose to start implementing the new WebSocket protocol which is discussed in IETF HyBi working group. Protocol draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09 JavaScript API draft: http://dev.w3.org/html5/websockets/ The new protocol is incompatible with the old one we are currently supporting. New additions include: - Binary frame support (Blob / ArrayBuffer) - Frame content masking (to solve security concern raised for the old draft) - Protocol extensions (such as frame compression) Because of the incompatibility, existing services using WebSockets are going to break. However, I think this is a necessary cost we have to pay eventually, because: - Other browsers are going to support the new protocol. (Firefox Aurora already includes support for the new protocol.) - The earlier we switch the protocols, the smaller shock there will be. Safari and Chrome are the only browsers that support WebSocket (the old protocol) by default. - There is a security concern raised for the protocol we are currently supporting. * How to proceed My original plan was to implement the new protocol directly (i.e. replacing the old implementation in-place). However Alexey (ap) objected to dropping support for the old protocol immediately. So, I'm currently planning to add a runtime flag to switch the WebSocket protocols used by a WebCore's WebSocket implementation. Other possibilities are to add a compile-time flag or to use (subversion's) branch, which are discussed at: https://bugs.webkit.org/show_bug.cgi?id=60348 The discussion in this bug has been stalled for a while, but I really would like to move forward. Comments and suggestions are greatly appreciated. Regards, Yuta ___ 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] Public APIs for accessing the Javascript debugger
Hi Alli, On Tue, Jun 14, 2011 at 7:38 AM, demallien demall...@me.com wrote: I'm interested in providing a public C API for accessing debugger functionality in JavascriptCore. Can you share the goals of this external API, and why the existing inspector infrastructure is not sufficient? Maybe if we better understood your goals, a suitable approach could be found that satisfied your goals without running afoul of Oliver's concerns. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing new WebSocket protocol
Reading that bug, Alexey's concerns seem to have been addressed by Firefox and IE shipping the new protocol. We don't want to ship something in between the old and new protocols though, so if it will take multiple patches to switch over, we should probably put it behind a runtime flag. On Tue, Jun 14, 2011 at 10:00 AM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We also said previously that we would remove the old protocol due to security concerns about poisoning caches/proxies. We justified not immediately disabling -00 like other browsers did by saying that a new version addressing the issue would come soon. We've had 9 new versions since and have yet to update, which is not good. Microsoft and Mozilla both are targeting newer drafts. Also, the protocol is in last call, and we're now at the point of just making editorial changes. It's stable, and it's time to update the implementation. On Tue, Jun 14, 2011 at 9:49 AM, Adam Barth aba...@webkit.org wrote: I think it's important to move forward with the new protocol. I'm not sure it matter too much what the transition plan is, but we should eventually remove the implementation of the old protocol from WebKit. No one else is going to implement the old protocol. Adam On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura yu...@chromium.org wrote: Hello, I would like to propose to start implementing the new WebSocket protocol which is discussed in IETF HyBi working group. Protocol draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09 JavaScript API draft: http://dev.w3.org/html5/websockets/ The new protocol is incompatible with the old one we are currently supporting. New additions include: - Binary frame support (Blob / ArrayBuffer) - Frame content masking (to solve security concern raised for the old draft) - Protocol extensions (such as frame compression) Because of the incompatibility, existing services using WebSockets are going to break. However, I think this is a necessary cost we have to pay eventually, because: - Other browsers are going to support the new protocol. (Firefox Aurora already includes support for the new protocol.) - The earlier we switch the protocols, the smaller shock there will be. Safari and Chrome are the only browsers that support WebSocket (the old protocol) by default. - There is a security concern raised for the protocol we are currently supporting. * How to proceed My original plan was to implement the new protocol directly (i.e. replacing the old implementation in-place). However Alexey (ap) objected to dropping support for the old protocol immediately. So, I'm currently planning to add a runtime flag to switch the WebSocket protocols used by a WebCore's WebSocket implementation. Other possibilities are to add a compile-time flag or to use (subversion's) branch, which are discussed at: https://bugs.webkit.org/show_bug.cgi?id=60348 The discussion in this bug has been stalled for a while, but I really would like to move forward. Comments and suggestions are greatly appreciated. Regards, Yuta ___ 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] bugs.webkit.org UI housekeeping
The e-mail notification for CC field changes is (among others) configurable in everyone's Bugzilla preferences. By default, only bug originator and assignee get an e-mail for that. I think that originators generally appreciate any kind of activity on their bugs, even as small as someone adding themselves to the CC list. That makes sense, thanks for the explanation. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing new WebSocket protocol
I thought Kitamura-san had patches mostly ready to switch us over? Either way, I agree we don't want to ship something in the middle, but I would verymuch like to see us shipping -09 by July at the latest. We've got a protocol that's stable, we've got external partners waiting to use this (esp. with binary data), we need to get it out the door. -Ian 2011/6/14 Ojan Vafai o...@chromium.org Reading that bug, Alexey's concerns seem to have been addressed by Firefox and IE shipping the new protocol. We don't want to ship something in between the old and new protocols though, so if it will take multiple patches to switch over, we should probably put it behind a runtime flag. On Tue, Jun 14, 2011 at 10:00 AM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We also said previously that we would remove the old protocol due to security concerns about poisoning caches/proxies. We justified not immediately disabling -00 like other browsers did by saying that a new version addressing the issue would come soon. We've had 9 new versions since and have yet to update, which is not good. Microsoft and Mozilla both are targeting newer drafts. Also, the protocol is in last call, and we're now at the point of just making editorial changes. It's stable, and it's time to update the implementation. On Tue, Jun 14, 2011 at 9:49 AM, Adam Barth aba...@webkit.org wrote: I think it's important to move forward with the new protocol. I'm not sure it matter too much what the transition plan is, but we should eventually remove the implementation of the old protocol from WebKit. No one else is going to implement the old protocol. Adam On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura yu...@chromium.org wrote: Hello, I would like to propose to start implementing the new WebSocket protocol which is discussed in IETF HyBi working group. Protocol draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09 JavaScript API draft: http://dev.w3.org/html5/websockets/ The new protocol is incompatible with the old one we are currently supporting. New additions include: - Binary frame support (Blob / ArrayBuffer) - Frame content masking (to solve security concern raised for the old draft) - Protocol extensions (such as frame compression) Because of the incompatibility, existing services using WebSockets are going to break. However, I think this is a necessary cost we have to pay eventually, because: - Other browsers are going to support the new protocol. (Firefox Aurora already includes support for the new protocol.) - The earlier we switch the protocols, the smaller shock there will be. Safari and Chrome are the only browsers that support WebSocket (the old protocol) by default. - There is a security concern raised for the protocol we are currently supporting. * How to proceed My original plan was to implement the new protocol directly (i.e. replacing the old implementation in-place). However Alexey (ap) objected to dropping support for the old protocol immediately. So, I'm currently planning to add a runtime flag to switch the WebSocket protocols used by a WebCore's WebSocket implementation. Other possibilities are to add a compile-time flag or to use (subversion's) branch, which are discussed at: https://bugs.webkit.org/show_bug.cgi?id=60348 The discussion in this bug has been stalled for a while, but I really would like to move forward. Comments and suggestions are greatly appreciated. Regards, Yuta ___ 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] Public APIs for accessing the Javascript debugger
Hi Brent, Sure. The goal of the debugger API is to allow client apps to create their own Javascript debugger as part of their browser. This isn't possible at the moment because the API is private, and hence you need to build the debugger code as part of Webkit to be able to access the header files. What I particularly do NOT want to have to do, is supply a special patched version of webkit to users of my own framework, that uses JavascriptCore as it's scripting language. Without trying to get ahead of the discussion, I was going to try just sticking copies of the relevant header files in my own project, and hoping that the needed symbols aren't stripped out of the lib. If that works, then things aren't too painful for me. It'll break if and when the private APIs change, but hey, that's what I get for using a private API... If the symbols have been stripped, then that WILL be painful to manage. I can't use the current inspector infrastructure because my application doesn't use webkit - think node.js (except it's scripting a custom graphics stack, not server-side code). We're running on a set top box, and don't even have a mouse available anyway... Alli On 14 juin 2011, at 19:44, Brent Fulgham wrote: Can you share the goals of this external API, and why the existing inspector infrastructure is not sufficient? Maybe if we better understood your goals, a suitable approach could be found that satisfied your goals without running afoul of Oliver's concerns. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing new WebSocket protocol
Getting on the latest protocol in place would be great, so long as we minimize the risk of anyone shipping a halfway mix. - Maciej On Jun 14, 2011, at 10:47 AM, Ian Fette (イアンフェッティ) wrote: I thought Kitamura-san had patches mostly ready to switch us over? Either way, I agree we don't want to ship something in the middle, but I would verymuch like to see us shipping -09 by July at the latest. We've got a protocol that's stable, we've got external partners waiting to use this (esp. with binary data), we need to get it out the door. -Ian 2011/6/14 Ojan Vafai o...@chromium.org Reading that bug, Alexey's concerns seem to have been addressed by Firefox and IE shipping the new protocol. We don't want to ship something in between the old and new protocols though, so if it will take multiple patches to switch over, we should probably put it behind a runtime flag. On Tue, Jun 14, 2011 at 10:00 AM, Ian Fette (イアンフェッティ) ife...@google.com wrote: We also said previously that we would remove the old protocol due to security concerns about poisoning caches/proxies. We justified not immediately disabling -00 like other browsers did by saying that a new version addressing the issue would come soon. We've had 9 new versions since and have yet to update, which is not good. Microsoft and Mozilla both are targeting newer drafts. Also, the protocol is in last call, and we're now at the point of just making editorial changes. It's stable, and it's time to update the implementation. On Tue, Jun 14, 2011 at 9:49 AM, Adam Barth aba...@webkit.org wrote: I think it's important to move forward with the new protocol. I'm not sure it matter too much what the transition plan is, but we should eventually remove the implementation of the old protocol from WebKit. No one else is going to implement the old protocol. Adam On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura yu...@chromium.org wrote: Hello, I would like to propose to start implementing the new WebSocket protocol which is discussed in IETF HyBi working group. Protocol draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09 JavaScript API draft: http://dev.w3.org/html5/websockets/ The new protocol is incompatible with the old one we are currently supporting. New additions include: - Binary frame support (Blob / ArrayBuffer) - Frame content masking (to solve security concern raised for the old draft) - Protocol extensions (such as frame compression) Because of the incompatibility, existing services using WebSockets are going to break. However, I think this is a necessary cost we have to pay eventually, because: - Other browsers are going to support the new protocol. (Firefox Aurora already includes support for the new protocol.) - The earlier we switch the protocols, the smaller shock there will be. Safari and Chrome are the only browsers that support WebSocket (the old protocol) by default. - There is a security concern raised for the protocol we are currently supporting. * How to proceed My original plan was to implement the new protocol directly (i.e. replacing the old implementation in-place). However Alexey (ap) objected to dropping support for the old protocol immediately. So, I'm currently planning to add a runtime flag to switch the WebSocket protocols used by a WebCore's WebSocket implementation. Other possibilities are to add a compile-time flag or to use (subversion's) branch, which are discussed at: https://bugs.webkit.org/show_bug.cgi?id=60348 The discussion in this bug has been stalled for a while, but I really would like to move forward. Comments and suggestions are greatly appreciated. Regards, Yuta ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
