[webkit-dev] Using Google-URL in WebKit

[Darin Fisher]

On Thu, Oct 2, 2008 at 2:23 PM, Maciej Stachowiak <mjs at apple.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/12b6b5e6/attachment.html