Re: [webkit-dev] Changing the implementation of KURL
On Jan 28, 2012, at 8:01 PM, Darin Fisher wrote: Right. In Firefox, the problem was that the cookie code used some hand-rolled string parsing code instead of reusing the URL parsing code. That resulted in a subtle bug that could be exploited to steal cookies. In Safari's case, I believe it was caused by differences between CFNetwork and KURL. If CFNetwork exposed an API to its URL parser, then it would be super wise for any port of WebKit using CFNetwork to reuse the same URL parser. CFNetwork's URL parser is exposed as public API, in the form of CFURL. However, CFURL is designed for historical RFC compliance rather than for Web compatibility. It's not really a practical option at this time. Perhaps in due course, CFURL could be changed to use WTFURL under the covers, or offer a mode to do so. But planning that sort of thing would be outside the scope of this mailing list. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Fri, Jan 27, 2012 at 9:44 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. I still think it is a bit backwards for Chromium's network stack to depend on WebKit, but I remain open minded about this. I'm curious how it will work out. The general approach I had in mind was to view WTFURL as a separate library that just happens to be hosted at svn.webkit.org. That requires some careful managing of dependencies but it seems worth trying. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
-Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Adam Barth Sent: Saturday, January 28, 2012 3:20 AM To: Darin Fisher Cc: Benjamin Poulain; WebKit Development Subject: Re: [webkit-dev] Changing the implementation of KURL The general approach I had in mind was to view WTFURL as a separate library that just happens to be hosted at svn.webkit.org. That requires some careful managing of dependencies but it seems worth trying. It would be handy if WTF as a whole could be used as a platform utility library. WTF::String in particular to stop string classes from multiplying: if the platform's network stack return headers as C strings, and you want to do some munging before passing them to WebKit, you can avoid data copies by converting them to WTF::String as soon as possible, rather than converting from C strings to (say) std::string and then again to WTF::String on entering webkit. While we're talking about hosting utility libraries that only some ports would use, it would be REALLY handy to have One True Cookie Parser, since right now WebKit leaves it to the network stack, and there are so many stacks that have substandard or non-existant cookie parsers that need to be reimplemented. Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 12:19 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 9:44 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. I still think it is a bit backwards for Chromium's network stack to depend on WebKit, but I remain open minded about this. I'm curious how it will work out. The general approach I had in mind was to view WTFURL as a separate library that just happens to be hosted at svn.webkit.org. That requires some careful managing of dependencies but it seems worth trying. I don't really want to reopen this debate, but how is that different than checking GoogleURL into webkit? Maciej was saying that this would impose an unacceptable burden on WebKit developers. I'm wondering what his specific complaints about burden are and whether they might also apply to a standalone WTFURL class. For example, if Maciej is concerned about coding style, we can easily fix that either way and it's a non-issue. If the concern is familiarity, I'm not sure I see the difference between Adam reimplementing WTFURL and using some existing code since they're both new code from the perspective of average WebKit contributors. I'm asking because I suspect Maciej's main concern is control over the library and dependencies and the ability to easily make changes necessary for Apple and WebKit (I would be worried about this, too). From my perspective, however, this might imply that he would want the ability in the future to make modifications and add dependencies that would be nonstarters with respect to Chromium's requirements. The normal answer (which I agree with) when some random port wants to do something weird and be able to compile without, for example, JavaScript, is that WebKit doesn't support these one-off use cases, take the whole thing and we should agree that this reasoning wouldn't apply to dependencies on the URL component. I think there was some agreement last year when the first part of this project happened. If we restart it, I would want to again make sure that everybody really understands what our dependency requirements are and agree that we're not going to be changing them because it's better for the WebKit community (c.f. Joe Mason's request to use all of WTF). I also worry that this will be a 9 month project for Adam, as the current partially done parsing thing took longer than anybody would have liked. Personally I would prefer Adam spend time fixing my security bugs :) So I want to be explicit on what Apple perceives as the benefit of Adam writes a bunch of new well-tested code with no dependencies vs. copy existing well-tested code with no dependencies into third_party and possibly reformat so we can make sure there are no surprises later. That said, I am quite supportive of you unification work for the benefit of WebKit! Brett ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Jan 28, 2012, at 9:24 AM, Brett Wilson wrote: On Sat, Jan 28, 2012 at 12:19 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 9:44 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. I still think it is a bit backwards for Chromium's network stack to depend on WebKit, but I remain open minded about this. I'm curious how it will work out. The general approach I had in mind was to view WTFURL as a separate library that just happens to be hosted at svn.webkit.org. That requires some careful managing of dependencies but it seems worth trying. I don't really want to reopen this debate, but how is that different than checking GoogleURL into webkit? Maciej was saying that this would impose an unacceptable burden on WebKit developers. I'm wondering what his specific complaints about burden are and whether they might also apply to a standalone WTFURL class. For example, if Maciej is concerned about coding style, we can easily fix that either way and it's a non-issue. If the concern is familiarity, I'm not sure I see the difference between Adam reimplementing WTFURL and using some existing code since they're both new code from the perspective of average WebKit contributors. I don't think anyone is expecting to implement new URL code from scratch. The proposals that were put forward are, as I understand them: (1) Check in GoogleURL as-is into the ThirdParty directory as an external dependency; future maintenance would be done via the canonical GoogleURL repository. (2) Check in GoogleURL as a proper part of WebKit, adapting its coding style and wrapping it in a way that works well with other WebKit/WTF data types. The issue is not new code or not, but the ability to maintain it going forward. I'm asking because I suspect Maciej's main concern is control over the library and dependencies and the ability to easily make changes necessary for Apple and WebKit (I would be worried about this, too). That's exactly it. From my perspective, however, this might imply that he would want the ability in the future to make modifications and add dependencies that would be nonstarters with respect to Chromium's requirements. The normal answer (which I agree with) when some random port wants to do something weird and be able to compile without, for example, JavaScript, is that WebKit doesn't support these one-off use cases, take the whole thing and we should agree that this reasoning wouldn't apply to dependencies on the URL component. I think there was some agreement last year when the first part of this project happened. If we restart it, I would want to again make sure that everybody really understands what our dependency requirements are and agree that we're not going to be changing them because it's better for the WebKit community (c.f. Joe Mason's request to use all of WTF). I also worry that this will be a 9 month project for Adam, as the current partially done parsing thing took longer than anybody would have liked. Personally I would prefer Adam spend time fixing my security bugs :) So I want to be explicit on what Apple perceives as the benefit of Adam writes a bunch of new well-tested code with no dependencies vs. copy existing well-tested code with no dependencies into third_party and possibly reformat so we can make sure there are no surprises later. I think that, at this point, Benjamin is volunteering to do the bulk of work and Adam is offering to help. The code would be more along the lines of reformatting and refactoring than write[ing] a bunch of new code as I understand it. I understand your concern about wanting to keept his code free of unwanted dependencies. However, we do already have a pretty hard boundary that WTF can't depend on anything higher in the stack. We could make WTFURL even more restricted if that was necessary or helpful. However, I think most of us who do not work on Chromium are not clear on what exactly the dependency constraints are. It would be helpful if you or Adam or someone else could document them. Let's take some specific examples. Would using WTF::Vector inside the implementation (not necessarily at the API boundary, just internally) be acceptable? Or would it be required to use C arrays or std::vector? Would using WTF's ASSERT family of macros be acceptable, or
Re: [webkit-dev] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2012, at 9:24 AM, Brett Wilson wrote: On Sat, Jan 28, 2012 at 12:19 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 9:44 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. I still think it is a bit backwards for Chromium's network stack to depend on WebKit, but I remain open minded about this. I'm curious how it will work out. The general approach I had in mind was to view WTFURL as a separate library that just happens to be hosted at svn.webkit.org. That requires some careful managing of dependencies but it seems worth trying. I don't really want to reopen this debate, but how is that different than checking GoogleURL into webkit? Maciej was saying that this would impose an unacceptable burden on WebKit developers. I'm wondering what his specific complaints about burden are and whether they might also apply to a standalone WTFURL class. For example, if Maciej is concerned about coding style, we can easily fix that either way and it's a non-issue. If the concern is familiarity, I'm not sure I see the difference between Adam reimplementing WTFURL and using some existing code since they're both new code from the perspective of average WebKit contributors. I don't think anyone is expecting to implement new URL code from scratch. The proposals that were put forward are, as I understand them: (1) Check in GoogleURL as-is into the ThirdParty directory as an external dependency; future maintenance would be done via the canonical GoogleURL repository. (2) Check in GoogleURL as a proper part of WebKit, adapting its coding style and wrapping it in a way that works well with other WebKit/WTF data types. The issue is not new code or not, but the ability to maintain it going forward. That's great, thanks. I'm asking because I suspect Maciej's main concern is control over the library and dependencies and the ability to easily make changes necessary for Apple and WebKit (I would be worried about this, too). That's exactly it. From my perspective, however, this might imply that he would want the ability in the future to make modifications and add dependencies that would be nonstarters with respect to Chromium's requirements. The normal answer (which I agree with) when some random port wants to do something weird and be able to compile without, for example, JavaScript, is that WebKit doesn't support these one-off use cases, take the whole thing and we should agree that this reasoning wouldn't apply to dependencies on the URL component. I think there was some agreement last year when the first part of this project happened. If we restart it, I would want to again make sure that everybody really understands what our dependency requirements are and agree that we're not going to be changing them because it's better for the WebKit community (c.f. Joe Mason's request to use all of WTF). I also worry that this will be a 9 month project for Adam, as the current partially done parsing thing took longer than anybody would have liked. Personally I would prefer Adam spend time fixing my security bugs :) So I want to be explicit on what Apple perceives as the benefit of Adam writes a bunch of new well-tested code with no dependencies vs. copy existing well-tested code with no dependencies into third_party and possibly reformat so we can make sure there are no surprises later. I think that, at this point, Benjamin is volunteering to do the bulk of work and Adam is offering to help. The code would be more along the lines of reformatting and refactoring than write[ing] a bunch of new code as I understand it. I understand your concern about wanting to keept his code free of unwanted dependencies. However, we do already have a pretty hard boundary that WTF can't depend on anything higher in the stack. We could make WTFURL even more restricted if that was necessary or helpful. However, I think most of us who do not work on Chromium are not clear on what exactly the dependency constraints are. It would be helpful if you or Adam or someone else could document them. Let's take some specific examples. Would using WTF::Vector inside the implementation (not necessarily at the API boundary, just internally) be acceptable? Or
Re: [webkit-dev] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 4:48 PM, Brett Wilson bre...@chromium.org wrote: On Sat, Jan 28, 2012 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2012, at 9:24 AM, Brett Wilson wrote: On Sat, Jan 28, 2012 at 12:19 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 9:44 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. I still think it is a bit backwards for Chromium's network stack to depend on WebKit, but I remain open minded about this. I'm curious how it will work out. The general approach I had in mind was to view WTFURL as a separate library that just happens to be hosted at svn.webkit.org. That requires some careful managing of dependencies but it seems worth trying. I don't really want to reopen this debate, but how is that different than checking GoogleURL into webkit? Maciej was saying that this would impose an unacceptable burden on WebKit developers. I'm wondering what his specific complaints about burden are and whether they might also apply to a standalone WTFURL class. For example, if Maciej is concerned about coding style, we can easily fix that either way and it's a non-issue. If the concern is familiarity, I'm not sure I see the difference between Adam reimplementing WTFURL and using some existing code since they're both new code from the perspective of average WebKit contributors. I don't think anyone is expecting to implement new URL code from scratch. The proposals that were put forward are, as I understand them: (1) Check in GoogleURL as-is into the ThirdParty directory as an external dependency; future maintenance would be done via the canonical GoogleURL repository. (2) Check in GoogleURL as a proper part of WebKit, adapting its coding style and wrapping it in a way that works well with other WebKit/WTF data types. The issue is not new code or not, but the ability to maintain it going forward. That's great, thanks. I'm asking because I suspect Maciej's main concern is control over the library and dependencies and the ability to easily make changes necessary for Apple and WebKit (I would be worried about this, too). That's exactly it. From my perspective, however, this might imply that he would want the ability in the future to make modifications and add dependencies that would be nonstarters with respect to Chromium's requirements. The normal answer (which I agree with) when some random port wants to do something weird and be able to compile without, for example, JavaScript, is that WebKit doesn't support these one-off use cases, take the whole thing and we should agree that this reasoning wouldn't apply to dependencies on the URL component. I think there was some agreement last year when the first part of this project happened. If we restart it, I would want to again make sure that everybody really understands what our dependency requirements are and agree that we're not going to be changing them because it's better for the WebKit community (c.f. Joe Mason's request to use all of WTF). I also worry that this will be a 9 month project for Adam, as the current partially done parsing thing took longer than anybody would have liked. Personally I would prefer Adam spend time fixing my security bugs :) So I want to be explicit on what Apple perceives as the benefit of Adam writes a bunch of new well-tested code with no dependencies vs. copy existing well-tested code with no dependencies into third_party and possibly reformat so we can make sure there are no surprises later. I think that, at this point, Benjamin is volunteering to do the bulk of work and Adam is offering to help. The code would be more along the lines of reformatting and refactoring than write[ing] a bunch of new code as I understand it. I understand your concern about wanting to keept his code free of unwanted dependencies. However, we do already have a pretty hard boundary that WTF can't depend on anything higher in the stack. We could make WTFURL even more restricted if that was necessary or helpful. However, I think most of us who do not work on Chromium are not clear on what exactly the dependency constraints are. It would be helpful if you or Adam or someone else could document them. Let's take some specific examples. Would using WTF::Vector inside the implementation
Re: [webkit-dev] Changing the implementation of KURL
-Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak Sent: Saturday, January 28, 2012 7:08 PM To: Brett Wilson Cc: Benjamin Poulain; WebKit Development Subject: Re: [webkit-dev] Changing the implementation of KURL Let's take some specific examples. Would using WTF::Vector inside the implementation (not necessarily at the API boundary, just internally) be acceptable? Or would it be required to use C arrays or std::vector? Would using WTF's ASSERT family of macros be acceptable, or should some other form of asserts be used? The are examples I can think of where dependencies could simply be added in the course of trying to get the code to be in WebKit style. Another big potential dependency would be use of Platform.h and the ENABLE/USE/etc system of macros - I could easily see a new feature including special processing for a new URL scheme, similar to the way file: url's have slightly different parsing rules than http: urls. In this case we'd want to wrap the special handling in ENABLE(feature). (Arguably the url class should be flexible enough that you don't have to hardcode special handling for a scheme, though.) Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 5:28 PM, Joe Mason jma...@rim.com wrote: -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak Sent: Saturday, January 28, 2012 7:08 PM To: Brett Wilson Cc: Benjamin Poulain; WebKit Development Subject: Re: [webkit-dev] Changing the implementation of KURL Let's take some specific examples. Would using WTF::Vector inside the implementation (not necessarily at the API boundary, just internally) be acceptable? Or would it be required to use C arrays or std::vector? Would using WTF's ASSERT family of macros be acceptable, or should some other form of asserts be used? The are examples I can think of where dependencies could simply be added in the course of trying to get the code to be in WebKit style. Another big potential dependency would be use of Platform.h and the ENABLE/USE/etc system of macros - I could easily see a new feature including special processing for a new URL scheme, similar to the way file: url's have slightly different parsing rules than http: urls. In this case we'd want to wrap the special handling in ENABLE(feature). (Arguably the url class should be flexible enough that you don't have to hardcode special handling for a scheme, though.) I don't see that as being much of an issue. Google Safe Browsing can always write their own Platform.h that does what they need. Brett ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson bre...@chromium.org wrote: So to clarify, I think we need to keep the current architecture. Obviously WebKit needs a URL class that uses its String class, so WTFURL would probably be a wrapper around some core library for WebKit to use. Chromium would rewrite our GURL class to use the same core library and keep std::strings (we don't want all our browser-level code to have to convert std::string - WTF::String just like today we don't want to do the inverse in WebKit). I don't really get this point. With WTF linked statically, no matter how largish WTF, it will not cost much to use. You say you don't want to convert std::string-WTF::String and WTF::String at the browser level, but aren't you doing that a lot more with the current code? Parsing valid URL can probably be done without WTF. URL canonicalization is frequent in WebKit and I would think using String directly is a good idea. Same for modifying a URL. Chromium is the only ports that use the same URL Class in the whole stack. And it seems you do not want any dependencies on WTF. Maybe an alternative is to change this and convert KURL-GoogleURL on platform boundaries like the other ports? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
The other concern I have is about the stability of the API to the URL guts that GURL living in the chromium repository would depend on. Anyone changing the URL guts would need to be careful not to break that contract. This seems like it might be annoying for those who do not work on chromium. On Jan 28, 2012 5:43 PM, Brett Wilson bre...@chromium.org wrote: On Sat, Jan 28, 2012 at 5:28 PM, Joe Mason jma...@rim.com wrote: -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Maciej Stachowiak Sent: Saturday, January 28, 2012 7:08 PM To: Brett Wilson Cc: Benjamin Poulain; WebKit Development Subject: Re: [webkit-dev] Changing the implementation of KURL Let's take some specific examples. Would using WTF::Vector inside the implementation (not necessarily at the API boundary, just internally) be acceptable? Or would it be required to use C arrays or std::vector? Would using WTF's ASSERT family of macros be acceptable, or should some other form of asserts be used? The are examples I can think of where dependencies could simply be added in the course of trying to get the code to be in WebKit style. Another big potential dependency would be use of Platform.h and the ENABLE/USE/etc system of macros - I could easily see a new feature including special processing for a new URL scheme, similar to the way file: url's have slightly different parsing rules than http: urls. In this case we'd want to wrap the special handling in ENABLE(feature). (Arguably the url class should be flexible enough that you don't have to hardcode special handling for a scheme, though.) I don't see that as being much of an issue. Google Safe Browsing can always write their own Platform.h that does what they need. Brett ___ 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] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain benja...@webkit.org wrote: On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson bre...@chromium.org wrote: So to clarify, I think we need to keep the current architecture. Obviously WebKit needs a URL class that uses its String class, so WTFURL would probably be a wrapper around some core library for WebKit to use. Chromium would rewrite our GURL class to use the same core library and keep std::strings (we don't want all our browser-level code to have to convert std::string - WTF::String just like today we don't want to do the inverse in WebKit). I don't really get this point. With WTF linked statically, no matter how largish WTF, it will not cost much to use. You say you don't want to convert std::string-WTF::String and WTF::String at the browser level, but aren't you doing that a lot more with the current code? Parsing valid URL can probably be done without WTF. URL canonicalization is frequent in WebKit and I would think using String directly is a good idea. Same for modifying a URL. GURL abstracts the underlying storage so that the canonicalized URL is written directly into the proper type. As far as I can tell, there isn't much advantage to WTFURL committing to a particular string type. Chromium is the only ports that use the same URL Class in the whole stack. And it seems you do not want any dependencies on WTF. Maybe an alternative is to change this and convert KURL-GoogleURL on platform boundaries like the other ports? My guess is you won't be able to convince fishd to use different URL libraries at different layers in Chromium. There's a long history of that causing security vulnerabilities, both in Firefox and in Safari. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 6:01 PM, Adam Barth aba...@webkit.org wrote: On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain benja...@webkit.org wrote: On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson bre...@chromium.org wrote: So to clarify, I think we need to keep the current architecture. Obviously WebKit needs a URL class that uses its String class, so WTFURL would probably be a wrapper around some core library for WebKit to use. Chromium would rewrite our GURL class to use the same core library and keep std::strings (we don't want all our browser-level code to have to convert std::string - WTF::String just like today we don't want to do the inverse in WebKit). I don't really get this point. With WTF linked statically, no matter how largish WTF, it will not cost much to use. You say you don't want to convert std::string-WTF::String and WTF::String at the browser level, but aren't you doing that a lot more with the current code? Parsing valid URL can probably be done without WTF. URL canonicalization is frequent in WebKit and I would think using String directly is a good idea. Same for modifying a URL. GURL abstracts the underlying storage so that the canonicalized URL is written directly into the proper type. As far as I can tell, there isn't much advantage to WTFURL committing to a particular string type. Chromium is the only ports that use the same URL Class in the whole stack. And it seems you do not want any dependencies on WTF. Maybe an alternative is to change this and convert KURL-GoogleURL on platform boundaries like the other ports? My guess is you won't be able to convince fishd to use different URL libraries at different layers in Chromium. There's a long history of that causing security vulnerabilities, both in Firefox and in Safari. Right. In Firefox, the problem was that the cookie code used some hand-rolled string parsing code instead of reusing the URL parsing code. That resulted in a subtle bug that could be exploited to steal cookies. In Safari's case, I believe it was caused by differences between CFNetwork and KURL. If CFNetwork exposed an API to its URL parser, then it would be super wise for any port of WebKit using CFNetwork to reuse the same URL parser. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Sat, Jan 28, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote: If CFNetwork exposed an API to its URL parser, then it would be super wise for any port of WebKit using CFNetwork to reuse the same URL parser. That is an interesting idea. I always considered it would be beneficial to have a single implementation in order to have a consistent behavior and the same security/bug fixes. You have a good point, maybe it is in the interest of the ports to split KURL... Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher da...@chromium.org wrote: Instead of doing all of this work, have you considered just treating GoogleURL in much the same way as WebKit treats ANGLE? You could perhaps just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit as a whole could switch to a consistent KURL implementation. WTFURL is a copy of GoogleURL adapted to WebKit so I hope it is not gonna be too much work (tm). :) As I understand, it was decided 2 years ago not to add GoogleURL into Source/ThirdParty to avoid pulling some dependencies and to have this important piece part of the WebKit project (I was not at that particular session). Also, be mindful that if your goal is to avoid having two implementions of KURL, then part of accomplishing that goal is also switching Chromium over to WTFURL. I'm guessing that is probably not in your plans. Do you know if someone is motivated to make that happen? (Chromium consumes GoogleURL directly, albeit mostly through the GURL front-end, which might be portable to WTFURL.) I assumed Adam Barth could help since he bootstrapped the whole WTFURL project. If there is no interest from Chromium to get rid of the split, I would rather keep improving the current KURL than completely switch the implementation. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain benja...@webkit.orgwrote: On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher da...@chromium.org wrote: Instead of doing all of this work, have you considered just treating GoogleURL in much the same way as WebKit treats ANGLE? You could perhaps just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit as a whole could switch to a consistent KURL implementation. WTFURL is a copy of GoogleURL adapted to WebKit so I hope it is not gonna be too much work (tm). :) As I understand, it was decided 2 years ago not to add GoogleURL into Source/ThirdParty to avoid pulling some dependencies and to have this important piece part of the WebKit project (I was not at that particular session). Source/ThirdParty didn't exist until Aug 2010, when ANGLE was imported. Before ThirdParty, there wasn't much of a convention of adding wholesale third-party libraries to WebKit. There certainly was a decision made at the earlier WebKit summit to copy GoogleURL into WebKit, and massage it there as a path toward having only one KURL implementation. My point was just that the work remaining to complete that effort isn't negligible. Also, we seem to be successfully sharing ANGLE as-is, and that is also a very critical piece of software (impacting web browser security), so why not the same approach for the GoogleURL library? I guess, I'm explicitly re-opening the conversation on this topic because it seems like the WTFURL approach will be a fair bit of work :-) Also, be mindful that if your goal is to avoid having two implementions of KURL, then part of accomplishing that goal is also switching Chromium over to WTFURL. I'm guessing that is probably not in your plans. Do you know if someone is motivated to make that happen? (Chromium consumes GoogleURL directly, albeit mostly through the GURL front-end, which might be portable to WTFURL.) I assumed Adam Barth could help since he bootstrapped the whole WTFURL project. I don't know... I wouldn't rule it out! If there is no interest from Chromium to get rid of the split, I would rather keep improving the current KURL than completely switch the implementation. I'm personally supportive of their being only one KURL implementation. I think most people are. I just think you get there immediately by using GoogleURL directly. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
As one data point, GoogleURL is quite stable. If you look at the changes http://code.google.com/p/google-url/source/list, there's only about one commit a month. Adam On Fri, Jan 27, 2012 at 12:22 AM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain benja...@webkit.org wrote: On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher da...@chromium.org wrote: Instead of doing all of this work, have you considered just treating GoogleURL in much the same way as WebKit treats ANGLE? You could perhaps just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit as a whole could switch to a consistent KURL implementation. WTFURL is a copy of GoogleURL adapted to WebKit so I hope it is not gonna be too much work (tm). :) As I understand, it was decided 2 years ago not to add GoogleURL into Source/ThirdParty to avoid pulling some dependencies and to have this important piece part of the WebKit project (I was not at that particular session). Source/ThirdParty didn't exist until Aug 2010, when ANGLE was imported. Before ThirdParty, there wasn't much of a convention of adding wholesale third-party libraries to WebKit. There certainly was a decision made at the earlier WebKit summit to copy GoogleURL into WebKit, and massage it there as a path toward having only one KURL implementation. My point was just that the work remaining to complete that effort isn't negligible. Also, we seem to be successfully sharing ANGLE as-is, and that is also a very critical piece of software (impacting web browser security), so why not the same approach for the GoogleURL library? I guess, I'm explicitly re-opening the conversation on this topic because it seems like the WTFURL approach will be a fair bit of work :-) Also, be mindful that if your goal is to avoid having two implementions of KURL, then part of accomplishing that goal is also switching Chromium over to WTFURL. I'm guessing that is probably not in your plans. Do you know if someone is motivated to make that happen? (Chromium consumes GoogleURL directly, albeit mostly through the GURL front-end, which might be portable to WTFURL.) I assumed Adam Barth could help since he bootstrapped the whole WTFURL project. I don't know... I wouldn't rule it out! If there is no interest from Chromium to get rid of the split, I would rather keep improving the current KURL than completely switch the implementation. I'm personally supportive of their being only one KURL implementation. I think most people are. I just think you get there immediately by using GoogleURL directly. -Darin ___ 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] Changing the implementation of KURL
On Jan 27, 2012, at 12:22 AM, Darin Fisher wrote: On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain benja...@webkit.org wrote: On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher da...@chromium.org wrote: Instead of doing all of this work, have you considered just treating GoogleURL in much the same way as WebKit treats ANGLE? You could perhaps just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit as a whole could switch to a consistent KURL implementation. WTFURL is a copy of GoogleURL adapted to WebKit so I hope it is not gonna be too much work (tm). :) As I understand, it was decided 2 years ago not to add GoogleURL into Source/ThirdParty to avoid pulling some dependencies and to have this important piece part of the WebKit project (I was not at that particular session). Source/ThirdParty didn't exist until Aug 2010, when ANGLE was imported. Before ThirdParty, there wasn't much of a convention of adding wholesale third-party libraries to WebKit. There certainly was a decision made at the earlier WebKit summit to copy GoogleURL into WebKit, and massage it there as a path toward having only one KURL implementation. My point was just that the work remaining to complete that effort isn't negligible. Also, we seem to be successfully sharing ANGLE as-is, and that is also a very critical piece of software (impacting web browser security), so why not the same approach for the GoogleURL library? I guess, I'm explicitly re-opening the conversation on this topic because it seems like the WTFURL approach will be a fair bit of work :-) URL parsing is both much less code than ANGLE, and much more core to what a browser engine does. It's also code that exists in WebCore today, albeit in buggy form, while ANGLE provided something brand new. And finally, URL processing is performance-critical in ordinary page loading, while what ANGLE does is only relevant to WebGL performance. These seem like good reasons to have URL parsing code more integrated than the ThirdParty approach. URL parsing seems more like, say, CSS parsing or HTML parsing than like GL sanitization in this regard. I hope most would agree that replacing the CSS parser or the HTML parser with an external dependency would not be a good long-term move, even if the external component was initially less buggy. While the proposed plan involves some effort up front, it seems less likely to create issues for non-Google contributors with a need to hack on URL processing in the future, as compared to the ThirdParty approach. That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Jan 27, 2012, at 2:39 AM, Adam Barth wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. Awesome! If you guys can work out the details, then I think that would be a great outcome. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak m...@apple.com wrote: That said, this plan was based on the premise that Chromium folks were willing to cooperate with the unforking effort, and would be happy to use a WebKit-integrated URL library based on GoogleURL. If that is no longer the case, then certainly we should not proceed on a false premise. I've been talking a bit with Benjamin about this topic off-list. I'm hopeful that with some careful attention to dependencies and interfaces, Chromium will be able to use WTFURL in place of GoogleURL. Adam I still think it is a bit backwards for Chromium's network stack to depend on WebKit, but I remain open minded about this. I'm curious how it will work out. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Changing the implementation of KURL
Hello, I would like to give another shot at the URL implementation Adam started some times ago. There are a few problems with the current KURL: -there are two implementations: WebKit and Google URL -some stuff are just plain incorrect :) -the WebKit implementation has some bugs which makes it differs from GoogleURL (and in some cases, the other engines) So I would like to: 1) put back WTF URL in trunk 2) add an implementation of KURL based on ParsedURL with a new USE(WTFURL) 3) fix the tests until we match at least the current KURL 4) fix the performance gap, if any 5) kill the current KURL, remove the flag USE(WTFURL) 6) fix the remaining tests If that fails. We can get rid of USE(WTFURL), and resume fixing the bug for current's KURL. Any comments? Suggestions? Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing the implementation of KURL
On Thu, Jan 26, 2012 at 6:11 PM, Benjamin Poulain benja...@webkit.orgwrote: Hello, I would like to give another shot at the URL implementation Adam started some times ago. There are a few problems with the current KURL: -there are two implementations: WebKit and Google URL -some stuff are just plain incorrect :) -the WebKit implementation has some bugs which makes it differs from GoogleURL (and in some cases, the other engines) So I would like to: 1) put back WTF URL in trunk 2) add an implementation of KURL based on ParsedURL with a new USE(WTFURL) 3) fix the tests until we match at least the current KURL 4) fix the performance gap, if any 5) kill the current KURL, remove the flag USE(WTFURL) 6) fix the remaining tests If that fails. We can get rid of USE(WTFURL), and resume fixing the bug for current's KURL. Any comments? Suggestions? Instead of doing all of this work, have you considered just treating GoogleURL in much the same way as WebKit treats ANGLE? You could perhaps just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit as a whole could switch to a consistent KURL implementation. This alternative seems like a very small amount of work and yields almost all of the benefits of creating WTFURL. The only downside would seem to be the extra overhead associated with making changes to GoogleURL. Has that sort of cost been an issue with ANGLE? Do you anticipate wanting to make a lot of significant code changes, or would you primarily just be concerned about the ease of bug fixing? Also, be mindful that if your goal is to avoid having two implementions of KURL, then part of accomplishing that goal is also switching Chromium over to WTFURL. I'm guessing that is probably not in your plans. Do you know if someone is motivated to make that happen? (Chromium consumes GoogleURL directly, albeit mostly through the GURL front-end, which might be portable to WTFURL.) Regards, -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
