[webkit-dev] Using Google-URL in WebKit

[David Hyatt]

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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev