[webkit-dev] Using Google-URL in WebKit

[Darin Fisher]

On Thu, Oct 2, 2008 at 3:43 PM, David Hyatt <hyatt at apple.com> wrote:

> On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote:
>
> On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt <hyatt at apple.com> wrote:
>
>> On Oct 2, 2008, at 4:23 PM, Maciej Stachowiak wrote:
>>
>> >>
>> >> 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 am strongly against integration of GURL behind KURL.  This code is
>> simple, and there's no reason to complicate it like this.  Any port
>> should be able to use KURL as is and just translate at boundaries
>> (like the existing Mac port does).  I don't think there should be any
>> major issues with this approach, and the alternative is to place a
>> burden on WebKit as far as having to maintain a now needlessly
>> complicated KURL class.
>>
>
>
> Hi Dave,
>
> Please see my comments on this thread.  Summarizing:  The code for correct
> and complete URL parsing / canonicalization is non-trivial and in many cases
> extremely subtle.  It is important to Chromium to use consistent URL
> handling across the entire application.  For example, our network stack
> depends on GoogleURL.  We have strong desire to share the same URL handling
> code with WebCore so that we achieve consistency, avoiding both correctness
> and security bugs.  It would be awkward to have our otherwise independent
> network stack suddenly depend on WebCore.
>
> All we are asking for is to add a couple #ifdefs to KURL.h so that we do
> not have to maintain a fork.  Is that really so hard to maintain going
> forward?  We are happy to do all of the work to maintain it.
>
>
> I would be ok with this if you don't place a burden on the other five ports
> to keep your version of KURL working.  In other words, if the API for KURL
> needs to be changed, it would be Google's responsibility to keep their
> GURL-backed version working.  That means checkins to KURL to change the API
> could break you going forward.  If you are ok with this, then I am ok with
> this.
>


Yup, we would not expect anyone else to be responsible for the #ifdefs that
we introduce into WebKit.  Long-term, I'd really prefer not to have #ifdefs
at all in WebCore.  I'd rather work toward an abstraction that avoids them
(without performance overhead of course).  I think we can do that here, but
it is important to walk before running, and so the #ifdef is very helpful as
a starting point.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/245b8923/attachment.html