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
