On Oct 2, 2008, at 3:43 PM, David Hyatt wrote:
On Oct 2, 2008, at 5:35 PM, Darin Fisher wrote:
On Thu, Oct 2, 2008 at 3:27 PM, David Hyatt <[EMAIL PROTECTED]> 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.
I would rather we seriously look at a way to unfork the URL parsing
code, before discussing mechanics of how to keep it forked. We don't
normally put ifdef paths in core code in WebKit that the WebKit
project is not expected to maintain, so that certainly wouldn't be my
first choice. And I do believe it will waste people's time to have the
fork there even if there is a prominent notice that Google is expected
to do all the work to keep it working.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev