[webkit-dev] Long-term Google-URL integration plans
Brett Wilson
brettw at chromium.org
Thu Oct 2 16:43:35 PDT 2008
I posted earlier about adding an ifdef for the Google-URL library in
KURL.h. I thought I would also explain the current thinking on the
long term plans, which a number of people have expressed concern
about. The current ifdef approach is an incremental way for us to move
forward, both with out merge of forked WebCore files, and toward a
more unified URL handling infrastructure.
We are open to a wide variety of solutions. We have a requirement that
we can use the same backend for our application-layer URL handling
without adding WebKit types. It would need to have two modes: a 16-bit
character mode for web pages, and an 8-bit character mode for
interpreting network traffic. Where the code lives and what format the
code is in are less important.
I think the best goal to have at this point that satisfies everybody's
requirements is that there be an interface layer that KURL uses. This
interface would basically be the url_canon and url_parse interfaces in
Google-URL. The initial implementation of these interfaces would be
the Google-URL code, and they would live in some directory inside
WebKit in the WebKit coding style.
This code would have no WebCore, WTF, or STL types in it. Applications
like Chromium could (if they wanted)) implement their own URL objects
on top of this interface, just like KURL would be implemented on top
of it. Other applications could also use this code without taking a
dependency on WebKit (there has been some interest expressed about
Google-URL for this reason). This is basically splitting the current
library into two, along layers which are already designed into it
(with the exception of one std::vector in url_util.cc which is a bug).
The current Google-URL project would likely be abandoned.
The WebKit community currently has little knowledge about this library
today. Predicting the final outcome will be impossible until the
community has some experience with this code. They may find that the
code or approach of the library is unacceptable, and we'll have to
find another way forward. Assuming that the Google-URL library is
largely seen as an improvement to the codebase by the WebKit
community, what I have outlined here would be a perfectly acceptable
solution to us.
Brett
More information about the webkit-dev
mailing list