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
[webkit-dev] mac-ews for contributors
Hi all, I am a non-committer yet and I would like to see that my patches are working correctly on Mac platform as well when I upload them to bugzilla, but the mac-ews does not work for non-committers. It is laborious work to get r+ because I do not see if my patch fails on mac. What about if the mac-ews will be extended with contributors from the committers.py? Cheers, Roland This message was sent using IMP, the Internet Messaging Program. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] mac-ews for contributors
On Fri, Jan 27, 2012 at 1:14 AM, takacs.rol...@stud.u-szeged.hu wrote: I am a non-committer yet and I would like to see that my patches are working correctly on Mac platform as well when I upload them to bugzilla, but the mac-ews does not work for non-committers. It is laborious work to get r+ because I do not see if my patch fails on mac. What about if the mac-ews will be extended with contributors from the committers.py? That sounds fine to me, but I'll defer to Lucas now that he's in charge fo those machines. 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 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] mac-ews for contributors
Please file a bug and I'll look into turning it on next week. Thanks, Lucas On Jan 27, 2012, at 1:19 AM, Adam Barth wrote: On Fri, Jan 27, 2012 at 1:14 AM, takacs.rol...@stud.u-szeged.hu wrote: I am a non-committer yet and I would like to see that my patches are working correctly on Mac platform as well when I upload them to bugzilla, but the mac-ews does not work for non-committers. It is laborious work to get r+ because I do not see if my patch fails on mac. What about if the mac-ews will be extended with contributors from the committers.py? That sounds fine to me, but I'll defer to Lucas now that he's in charge fo those machines. 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 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
