[webkit-dev] Long-term Google-URL integration plans

[Brett Wilson]

On Thu, Oct 2, 2008 at 4:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> I also do not find the current interfaces of url_canon or url_parse
> particularly congenial, so we should also keep an open mind on what the
> interface to this code would look like. Is that ok with you?

Some background: url_parse and url_canon are designed to be very
low-level and flexible. They are not actually intended to be used
directly by an application. They are intended to be used by a wrapper
object that can be written using any generic string type, 8- or 16-bit
string inputs. The current interface certainly isn't perfect, but I
think it's about what you get with these requirements.

On top of this layer is the url_util layer. This is what GURL and KURL
are really implemented in terms of, and it's actually quite simple. It
calls the correct lower-level functions in the ways that they were
intended to be called. Sometimes it's convenient to bypass this, and
we occationally do. It's nice that the application has the option to
do either.

You can see the GURL object has both a relatively clean interface and
relatively little logic inside of it.

As you say, the exact interface to the lower layers is unimportant as
long as it meets the needs of both objects.


>> This code would have no WebCore, WTF, or STL types in it.
>
> I'd like to relax this and say WTF types should be ok as long as they are
> moved to the same dependency level and have an equally liberal license. For
> instance, I don't see the win of the URL library having a separate class for
> a resizable buffer with possible stack backing store for small buffers,
> rather than using WTF::Vector. Similarly, if any unicode processing is
> needed, it would be nice to use WTF's unicode library abstraction layer for
> ports that do not use ICU but have a different source of unicode
> functionality (I think that's only the Qt port currently).
>
>> 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.
>
> I have a copy of the library checked out from SVN (have for quite some time)
> and I have studied the code. But I will admit I don't know much about how
> well it works.

I think when you can run it in Safari, you'll feel more strongly about
it one way or the other :)


[moved from the beginning of the message]
> I'd like to not assume up front that the code used to implement the URL
> parsing core will be Google-URL. Maybe Google-URL's code will turn out to be
> better, maybe the current KURL implementation will. I'm willing to keep an
> open mind about this until we can do some comparisons. Are you also willing
> to keep an open mind about which implementation is the basis of a shared
> one?

You should not be accepting this code because you're doing a favor for
us. You should accept it because you think that there's a good chance
you will eventually end up with a better URL implementation. If you
don't think this is the case, please let me know. I would rather spend
my efforts maintaining a fork of KURL than arguing about why you
should do something you don't want. I've probably spent only one day
all year merging KURL, so the status quo will be significantly less
work for me personally.

If we check it in with ifdefs, you evaluate the details of the
implementation, and you think that the current KURL code is better
than Google-URL, then I think this status quo is easier for both of
us. Nothing precludes this from happening. This is why I was very
clear about "evaluation" and that you may find it "unacceptable,"
which is OK. I will volunteer to do the work necessary to factor the
code as necessary if you decide you like it.

Brett