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

[Maciej Stachowiak]

This plan seems generally ok, a few comments:

On Oct 2, 2008, at 4:43 PM, Brett Wilson wrote:

> 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.

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?

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?

> 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.

Anyway, I am ok with this something along these lines with the caveats  
mentioned above.

Does anyone else have comments?

Regards,
Maciej