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
