Re: [webkit-dev] Using Google-URL in WebKit
Kind of an unrelated note, but it would be nice to rename KURL to something else e.g., WebCoreURL, URL, WebURL, etc. dave On Oct 2, 2008, at 3:07 PM, Brett Wilson wrote: About a year ago, Google released the Google URL Parsing and Canonicalization Library (Google-URL) as a separate open-source project: http://code.google.com/p/google-url It was developed for Chromium with an eye toward being used in other client apps at Google and elsewhere. We think there are a number of advantages of this library over the current KURL code, but I'm not trying to sell anybody on using it or have a big debate about its merits at this time. (Our most important constraint is that we want our application layer and our WebKit layer to agree on parsing for security and other types of mismatch bugs.) I have mentioned optionally replacing KURL with an ifdef to a number of WebKit members. The reception has been tentatively yes. There are a number of reasons to do it: 1. Chromium has this file forked and we can't unfork until at least the header files are resolved. This prevents us from working as close to the tip of tree and would probably limit our WebKit contributions. I would also like to make some changes throughout WebKit that would help our implementation of KURL, but would also help the current implementation. This would only be possible if the code was more unified. 2. It allows the WebKit community to experiment with it. The current state of affairs is that nobody outside of Google knows much about the library which prevents detailed technical discussions from taking place. Even if full adoption of the library never happens, I think some familiarity with what we did will help future URL parsing and canonicalization work the WebKit community may approach. When everybody can try it out then there can be a much better discussion about whether other ports might want to use it, of the library's strengths and weaknesses, and possible additions and changes that people may want to see. Current state of affairs: You can see our forked version of KURL.h here: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/pending/KURL.h?view=markup Our implementation is here: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL.cpp?view=markup http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL_unittest.cpp?view=markup We keep the ability to compile with the Google-URL KURL or the WebCore KURL (we use this for testing) so the final file in the WebKit tree would work similarly. You will notice, however, that this file is a mess and you probably wouldn't want it as-is. It grew organically in such a way as to minimize the changes relative to the upstream KURL.h. Proposals/Questions: I'd like to add the ability to compile KURL using a Google-URL backend to the WebKit trunk under some kind of #ifdef. The default WebKit build would see no change in functionality. 1. I don't have any particular preference for the exact ifdef. I think USE(GOOGLEURL) would be appropriate. 2. I propose to move most of the functions and data additions of our current KURL.h linked above into a KURLPrivate object which is in another header file (or KURLGoogleURL.h?). It would be included at the top of the file controlled by the ifdef. Non Google-URL projects would just not use this object/header file. This will eliminate most of the additions while keeping the current code mostly the same. The private section of the class would look like: #if USE(GOOGLEURL) KURLPrivate p; #else ... current data members. #endif I can move the current data into a Private class as well if you would prefer, which would eliminate further ifdefs but may make it more difficult to follow. 3. Grouping the other code in our current ifdefs should make more of the clutter go away. Alternatively, most of the diffs in the header file (like string getters, isNull, etc.) could be completely eliminated if the functions were implemented in the .cpp file rather than inline. I don't think that this would be a performance hit and would prefer this approach, but others may disagree. There may be some subset of functions where this makes sense. 4. The Google-URL library would not be checked into WebKit. Those wishing to use it would install it locally in such a place that #include googleurl/src/foo.h like Chromium uses now would work. Comments and questions would be welcome, 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] Using Google-URL in WebKit
WURL? Short, but has the required letters -- though perhaps sounds too funny. Alex On Oct 2, 2008, at 3:10 PM, David Hyatt wrote: Kind of an unrelated note, but it would be nice to rename KURL to something else e.g., WebCoreURL, URL, WebURL, etc. dave On Oct 2, 2008, at 3:07 PM, Brett Wilson wrote: About a year ago, Google released the Google URL Parsing and Canonicalization Library (Google-URL) as a separate open-source project: http://code.google.com/p/google-url It was developed for Chromium with an eye toward being used in other client apps at Google and elsewhere. We think there are a number of advantages of this library over the current KURL code, but I'm not trying to sell anybody on using it or have a big debate about its merits at this time. (Our most important constraint is that we want our application layer and our WebKit layer to agree on parsing for security and other types of mismatch bugs.) I have mentioned optionally replacing KURL with an ifdef to a number of WebKit members. The reception has been tentatively yes. There are a number of reasons to do it: 1. Chromium has this file forked and we can't unfork until at least the header files are resolved. This prevents us from working as close to the tip of tree and would probably limit our WebKit contributions. I would also like to make some changes throughout WebKit that would help our implementation of KURL, but would also help the current implementation. This would only be possible if the code was more unified. 2. It allows the WebKit community to experiment with it. The current state of affairs is that nobody outside of Google knows much about the library which prevents detailed technical discussions from taking place. Even if full adoption of the library never happens, I think some familiarity with what we did will help future URL parsing and canonicalization work the WebKit community may approach. When everybody can try it out then there can be a much better discussion about whether other ports might want to use it, of the library's strengths and weaknesses, and possible additions and changes that people may want to see. Current state of affairs: You can see our forked version of KURL.h here: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/pending/KURL.h?view=markup Our implementation is here: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL.cpp?view=markup http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL_unittest.cpp?view=markup We keep the ability to compile with the Google-URL KURL or the WebCore KURL (we use this for testing) so the final file in the WebKit tree would work similarly. You will notice, however, that this file is a mess and you probably wouldn't want it as-is. It grew organically in such a way as to minimize the changes relative to the upstream KURL.h. Proposals/Questions: I'd like to add the ability to compile KURL using a Google-URL backend to the WebKit trunk under some kind of #ifdef. The default WebKit build would see no change in functionality. 1. I don't have any particular preference for the exact ifdef. I think USE(GOOGLEURL) would be appropriate. 2. I propose to move most of the functions and data additions of our current KURL.h linked above into a KURLPrivate object which is in another header file (or KURLGoogleURL.h?). It would be included at the top of the file controlled by the ifdef. Non Google-URL projects would just not use this object/header file. This will eliminate most of the additions while keeping the current code mostly the same. The private section of the class would look like: #if USE(GOOGLEURL) KURLPrivate p; #else ... current data members. #endif I can move the current data into a Private class as well if you would prefer, which would eliminate further ifdefs but may make it more difficult to follow. 3. Grouping the other code in our current ifdefs should make more of the clutter go away. Alternatively, most of the diffs in the header file (like string getters, isNull, etc.) could be completely eliminated if the functions were implemented in the .cpp file rather than inline. I don't think that this would be a performance hit and would prefer this approach, but others may disagree. There may be some subset of functions where this makes sense. 4. The Google-URL library would not be checked into WebKit. Those wishing to use it would install it locally in such a place that #include googleurl/src/foo.h like Chromium uses now would work. Comments and questions would be welcome, 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] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 1:13 PM, Alex Iskander [EMAIL PROTECTED] wrote: WURL? Short, but has the required letters -- though perhaps sounds too funny. We're using GURL which is pretty funny! Brett ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I consider the option of completely replacing WebKit's URL implementation with an external dependency to be a nonstarter. Assume that we wound up in a world where GURL formed the basis of the WebKit URL implementation. Does this statement mean you would copy the GURL sources into the WebKit tree and periodically recopy (kind of like Chromium does with a number of its dependencies, e.g. libxml, libjpeg, etc.)? Or that you would copy once and then ignore upstream (i.e. fork)? Or that you would not be willing to even consider basing anything off GURL code unless it moved from its current repository into the WebKit tree as its sole home (making it hard for any other project to use it)? Or some other possibility I've missed? There are already various dependencies of WebKit on other projects' code (e.g. sqlite) so I guess I'm trying to figure out how to parse this statement and whether you're saying that this section of the code is subject to different requirements. At least in the Chromium codebase, having pieces like googleurl be pulled in as external dependencies has not been problematic at all, and has been useful for other projects. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
It's kind of ridiculous to have an external dependency on a piece of code this tiny. dave On Oct 2, 2008, at 4:41 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I consider the option of completely replacing WebKit's URL implementation with an external dependency to be a nonstarter. Assume that we wound up in a world where GURL formed the basis of the WebKit URL implementation. Does this statement mean you would copy the GURL sources into the WebKit tree and periodically recopy (kind of like Chromium does with a number of its dependencies, e.g. libxml, libjpeg, etc.)? Or that you would copy once and then ignore upstream (i.e. fork)? Or that you would not be willing to even consider basing anything off GURL code unless it moved from its current repository into the WebKit tree as its sole home (making it hard for any other project to use it)? Or some other possibility I've missed? There are already various dependencies of WebKit on other projects' code (e.g. sqlite) so I guess I'm trying to figure out how to parse this statement and whether you're saying that this section of the code is subject to different requirements. At least in the Chromium codebase, having pieces like googleurl be pulled in as external dependencies has not been problematic at all, and has been useful for other projects. PK ___ 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] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 1:07 PM, Brett Wilson wrote: About a year ago, Google released the Google URL Parsing and Canonicalization Library (Google-URL) as a separate open-source project: http://code.google.com/p/google-url It was developed for Chromium with an eye toward being used in other client apps at Google and elsewhere. We think there are a number of advantages of this library over the current KURL code, but I'm not trying to sell anybody on using it or have a big debate about its merits at this time. (Our most important constraint is that we want our application layer and our WebKit layer to agree on parsing for security and other types of mismatch bugs.) I have mentioned optionally replacing KURL with an ifdef to a number of WebKit members. The reception has been tentatively yes. As one of the people who were asked and tentatively said yes, I would like to clarify that my agreement was conditional. Specifically, I'm ok with this as a temporary measure, as long as we are on track to eventually have a unified URL implementation. I think having our long- term solution be an ifdef to have two completely separate implementations of such a simple class (2000 lines of code for the current WebKit implementation) would be extremely silly. Also, we have plans to significantly redesign the interface of KURL, and having it ifdef'd to two different implementations will make that quite a bit harder. Also, the URL code is often a source of security or performance issues, and fixing them twice is a cost to the whole project. To clarify on track to eventually have a unified URL implementation, I specifically mean: 1) The Chromium engineers responsible for this area of code would agree in principle that we should work towards a unified URL parsing implementation. 2) We would have at least a rough outline for how the unification could happen. I think two plausible approaches are: (a) fix KURL to satisfy the requirements that drove the creation of Google-URL and drop the Google-URL fork of KURL; (b) integrate Google-URL into the WebKit project and drop the original code for KURL. As far as I am concerned, both of these options are on the table and the determinations should be made by criteria like performance, correctness, code quality, etc. I consider the option of completely replacing WebKit's URL implementation with an external dependency to be a nonstarter. 3) We would agree on a rough timeline on which we plan to make the unification happen; if it hasn't happened by then we'll plan to revisit this issue. Once we are set on points 1-3, I am ok with landing ifdefs as a transitional measure. Until then, I am not ok with such a change. Regards, Maciej I agree that it would be very nice to share implementations here. One thing I'd like to highlight: It is a requirement for Chromium to use consistent URL parsing throughout the entire application. This includes all processes, the network stack, etc. While we could invoke KURL to do so, it is hugely beneficial to us to be able to simply reuse the core elements of GoogleURL (url_canon, url_parse) via the GURL interface. So, we end up with GKURL used by WebCore and GURL used by the rest of Chromium, but both of those are just thin interface layers around GoogleURL's core. I think it would be very awkward (probably a non-starter) for us if we were not able to separate the KURL interface from the guts and reuse those guts efficiently in the other parts of our application. For example, those guts are entirely parameterized the string type, allowing us to substitute std::string for WebCore::String, and so on in a very efficient manner. The core elements of GoogleURL do not depend on any specific libraries, and that is very important for our reuse of it throughout our entire application. Hope this helps clarify why we have what we have. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Oct 2, 2008, at 2:41 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I consider the option of completely replacing WebKit's URL implementation with an external dependency to be a nonstarter. Assume that we wound up in a world where GURL formed the basis of the WebKit URL implementation. Does this statement mean you would copy the GURL sources into the WebKit tree and periodically recopy (kind of like Chromium does with a number of its dependencies, e.g. libxml, libjpeg, etc.)? Or that you would copy once and then ignore upstream (i.e. fork)? Or that you would not be willing to even consider basing anything off GURL code unless it moved from its current repository into the WebKit tree as its sole home (making it hard for any other project to use it)? Or some other possibility I've missed? Something that we had to do extra work to merge periodically would probably still seem like effectively an external dependency. There are already various dependencies of WebKit on other projects' code (e.g. sqlite) so I guess I'm trying to figure out how to parse this statement and whether you're saying that this section of the code is subject to different requirements. At least in the Chromium codebase, having pieces like googleurl be pulled in as external dependencies has not been problematic at all, and has been useful for other projects. We tend to use external dependencies when we don't have existing code to do the job, where an external library does the job, where the amount of code to write it ourselves would be large, and where the facility in question does not seem to be core to doing the work of a Web browser. We do not generally replace existing working code with an external dependency. We write our own new code rather than using a library when the other conditions above are not met. We are applying these concepts equally to the database code (large, complex facility; existing sqlite library does the job; we didn't have existing code to implement a SQL database; SQL database is not core to a browser) and the URL code (pretty small amount of code; we have existing code that works; URL parsing is core to a browser. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Oct 2, 2008, at 2:53 PM, Darin Fisher wrote: I agree that it would be very nice to share implementations here. One thing I'd like to highlight: It is a requirement for Chromium to use consistent URL parsing throughout the entire application. This includes all processes, the network stack, etc. While we could invoke KURL to do so, it is hugely beneficial to us to be able to simply reuse the core elements of GoogleURL (url_canon, url_parse) via the GURL interface. So, we end up with GKURL used by WebCore and GURL used by the rest of Chromium, but both of those are just thin interface layers around GoogleURL's core. I think it would be very awkward (probably a non-starter) for us if we were not able to separate the KURL interface from the guts and reuse those guts efficiently in the other parts of our application. For example, those guts are entirely parameterized the string type, allowing us to substitute std::string for WebCore::String, and so on in a very efficient manner. The core elements of GoogleURL do not depend on any specific libraries, and that is very important for our reuse of it throughout our entire application. Hope this helps clarify why we have what we have. I'd be open to WebCore exporting a more general or lower-level URL interface that is more readily usable from non-WebCore contexts, if KURL does not suit as-is. I should also note that, originally, our KURL was a wrapper on top of NSURL, since the app level and network layer for the Mac port use NSURL. We decided to drop that in favor of cross-platform code, and convert to NSURL as the boundaries. As far as I know, we have not had serious problems from mismatches, whether security or otherwise. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
One thing I'd like to highlight: It is a requirement for Chromium to use consistent URL parsing throughout the entire application. Can you explain this requirement more? I think that's an important data point, since other WebKit ports, including the Mac port, use KURL in WebKit and a different URL class in the app / platform layers -- so we may not be sufficiently familiar with why a single URL class is so important to Chrome. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 3:01 PM, Geoffrey Garen [EMAIL PROTECTED] wrote: One thing I'd like to highlight: It is a requirement for Chromium to use consistent URL parsing throughout the entire application. Can you explain this requirement more? I think that's an important data point, since other WebKit ports, including the Mac port, use KURL in WebKit and a different URL class in the app / platform layers -- so we may not be sufficiently familiar with why a single URL class is so important to Chrome. Sure. It helps us avoid security bugs that may be caused by inconsistent URL handling in different parts of the code base. This is very important to us. For example, canonicalization effects whether you consider two URL strings to be the same or different. This can impact the network stack, the download manager, the URL bar, the safe browsing system, the history system, etc. etc. In some cases it is just about correctness. In others it is about security. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote: I have mentioned optionally replacing KURL with an ifdef to a number of WebKit members. The reception has been tentatively yes. As one of the people who were asked and tentatively said yes, I am strongly against integration of GURL behind KURL. This code is simple, and there's no reason to complicate it like this. Any port should be able to use KURL as is and just translate at boundaries (like the existing Mac port does). I don't think there should be any major issues with this approach, and the alternative is to place a burden on WebKit as far as having to maintain a now needlessly complicated KURL class. Hi Dave, Please see my comments on this thread. Summarizing: The code for correct and complete URL parsing / canonicalization is non-trivial and in many cases extremely subtle. It is important to Chromium to use consistent URL handling across the entire application. For example, our network stack depends on GoogleURL. We have strong desire to share the same URL handling code with WebCore so that we achieve consistency, avoiding both correctness and security bugs. It would be awkward to have our otherwise independent network stack suddenly depend on WebCore. All we are asking for is to add a couple #ifdefs to KURL.h so that we do not have to maintain a fork. Is that really so hard to maintain going forward? We are happy to do all of the work to maintain it. Regards, -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote: I have mentioned optionally replacing KURL with an ifdef to a number of WebKit members. The reception has been tentatively yes. As one of the people who were asked and tentatively said yes, I am strongly against integration of GURL behind KURL. This code is simple, and there's no reason to complicate it like this. Any port should be able to use KURL as is and just translate at boundaries (like the existing Mac port does). I don't think there should be any major issues with this approach, and the alternative is to place a burden on WebKit as far as having to maintain a now needlessly complicated KURL class. Hi Dave, Please see my comments on this thread. Summarizing: The code for correct and complete URL parsing / canonicalization is non-trivial and in many cases extremely subtle. It is important to Chromium to use consistent URL handling across the entire application. For example, our network stack depends on GoogleURL. We have strong desire to share the same URL handling code with WebCore so that we achieve consistency, avoiding both correctness and security bugs. It would be awkward to have our otherwise independent network stack suddenly depend on WebCore. All we are asking for is to add a couple #ifdefs to KURL.h so that we do not have to maintain a fork. Is that really so hard to maintain going forward? We are happy to do all of the work to maintain it. I would be ok with this if you don't place a burden on the other five ports to keep your version of KURL working. In other words, if the API for KURL needs to be changed, it would be Google's responsibility to keep their GURL-backed version working. That means checkins to KURL to change the API could break you going forward. If you are ok with this, then I am ok with this. dave ([EMAIL PROTECTED]) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Oct 2, 2008, at 3:43 PM, David Hyatt wrote: On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote: I have mentioned optionally replacing KURL with an ifdef to a number of WebKit members. The reception has been tentatively yes. As one of the people who were asked and tentatively said yes, I am strongly against integration of GURL behind KURL. This code is simple, and there's no reason to complicate it like this. Any port should be able to use KURL as is and just translate at boundaries (like the existing Mac port does). I don't think there should be any major issues with this approach, and the alternative is to place a burden on WebKit as far as having to maintain a now needlessly complicated KURL class. Hi Dave, Please see my comments on this thread. Summarizing: The code for correct and complete URL parsing / canonicalization is non-trivial and in many cases extremely subtle. It is important to Chromium to use consistent URL handling across the entire application. For example, our network stack depends on GoogleURL. We have strong desire to share the same URL handling code with WebCore so that we achieve consistency, avoiding both correctness and security bugs. It would be awkward to have our otherwise independent network stack suddenly depend on WebCore. All we are asking for is to add a couple #ifdefs to KURL.h so that we do not have to maintain a fork. Is that really so hard to maintain going forward? We are happy to do all of the work to maintain it. I would be ok with this if you don't place a burden on the other five ports to keep your version of KURL working. In other words, if the API for KURL needs to be changed, it would be Google's responsibility to keep their GURL-backed version working. That means checkins to KURL to change the API could break you going forward. If you are ok with this, then I am ok with this. I would rather we seriously look at a way to unfork the URL parsing code, before discussing mechanics of how to keep it forked. We don't normally put ifdef paths in core code in WebKit that the WebKit project is not expected to maintain, so that certainly wouldn't be my first choice. And I do believe it will waste people's time to have the fork there even if there is a prominent notice that Google is expected to do all the work to keep it working. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
KURL depends on WebCore types, and was found to have bugs, so Brett did a study of other URL parsers and wrote the Google URL library as a template library (and wrote GURL as an example class using it with std::string). This part I don't get. Brett found some bugs. Why didn't he fix them? Did he file them, at least? Isn't that what participating in an open source project is all about? If Brett finds some bugs in layout and rendering, is head going to write a GCSS? Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 3:49 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I would rather we seriously look at a way to unfork the URL parsing code, before discussing mechanics of how to keep it forked. We don't normally put ifdef paths in core code in WebKit that the WebKit project is not expected to maintain, so that certainly wouldn't be my first choice. And I do believe it will waste people's time to have the fork there even if there is a prominent notice that Google is expected to do all the work to keep it working. We're trying to join the WebKit community as ongoing contributors, not dump work in your lap and run away (or even dump work in our own laps but stand apart from you). The WebKit community _would be_ expected to maintain these paths-- we're volunteering to do it as WebKit contributors and, hopefully, members of that community. The sooner it can stop being WebKit As Opposed To Google and start being all of us working together on making WebKit better, the better, IMO. And obviously we share your desire not to have two implementations long term. We're trying to work with you to avoid that; we already have it right now, it just exists as a fork of the WebKit tree into our tree, which is IMO even worse than ifdefs. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 3:43 PM, David Hyatt [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote: I have mentioned optionally replacing KURL with an ifdef to a number of WebKit members. The reception has been tentatively yes. As one of the people who were asked and tentatively said yes, I am strongly against integration of GURL behind KURL. This code is simple, and there's no reason to complicate it like this. Any port should be able to use KURL as is and just translate at boundaries (like the existing Mac port does). I don't think there should be any major issues with this approach, and the alternative is to place a burden on WebKit as far as having to maintain a now needlessly complicated KURL class. Hi Dave, Please see my comments on this thread. Summarizing: The code for correct and complete URL parsing / canonicalization is non-trivial and in many cases extremely subtle. It is important to Chromium to use consistent URL handling across the entire application. For example, our network stack depends on GoogleURL. We have strong desire to share the same URL handling code with WebCore so that we achieve consistency, avoiding both correctness and security bugs. It would be awkward to have our otherwise independent network stack suddenly depend on WebCore. All we are asking for is to add a couple #ifdefs to KURL.h so that we do not have to maintain a fork. Is that really so hard to maintain going forward? We are happy to do all of the work to maintain it. I would be ok with this if you don't place a burden on the other five ports to keep your version of KURL working. In other words, if the API for KURL needs to be changed, it would be Google's responsibility to keep their GURL-backed version working. That means checkins to KURL to change the API could break you going forward. If you are ok with this, then I am ok with this. Yup, we would not expect anyone else to be responsible for the #ifdefs that we introduce into WebKit. Long-term, I'd really prefer not to have #ifdefs at all in WebCore. I'd rather work toward an abstraction that avoids them (without performance overhead of course). I think we can do that here, but it is important to walk before running, and so the #ifdef is very helpful as a starting point. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Google-URL in WebKit
On Thu, Oct 2, 2008 at 3:53 PM, Geoffrey Garen [EMAIL PROTECTED] wrote: KURL depends on WebCore types, and was found to have bugs, so Brett did a study of other URL parsers and wrote the Google URL library as a template library (and wrote GURL as an example class using it with std::string). This part I don't get. Brett found some bugs. Why didn't he fix them? Did he file them, at least? Isn't that what participating in an open source project is all about? If Brett finds some bugs in layout and rendering, is head going to write a GCSS? I explained this on #webkit, but since that was easy to miss... we did not build GoogleURL because we thought KURL was buggy. We built GoogleURL because we needed to have consistent URL parsing and canonicalization throughout our entire application, including our network stack, download manager, and user interface. It was not until later that we went the full distance and wrote GKURL (again because we wanted to have consistent URL parsing and canonicalization throughout our entire application). We did our best to make GoogleURL match the quirks of Internet Explorer except in places where that did not make sense. Some of those behaviors may be interesting or may even be regarded as good RFE bugs for KURL, but they are not the reasons for GoogleURL's existence. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
