[webkit-dev] Using Google-URL in WebKit

[Brett Wilson]

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