[webkit-dev] Changing the implementation of KURL

[Brett Wilson]

On Sat, Jan 28, 2012 at 12:19 AM, Adam Barth <abarth at webkit.org> wrote:
> On Fri, Jan 27, 2012 at 9:44 PM, Darin Fisher <darin at chromium.org> wrote:
>> On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth <abarth at webkit.org> wrote:
>>> On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> > That said, this plan was based on the premise that Chromium folks were
>>> > willing to cooperate with the unforking effort, and would be happy to
>>> > use a
>>> > WebKit-integrated URL library based on GoogleURL. If that is no longer
>>> > the
>>> > case, then certainly we should not proceed on a false premise.
>>>
>>> I've been talking a bit with Benjamin about this topic off-list.  I'm
>>> hopeful that with some careful attention to dependencies and
>>> interfaces, Chromium will be able to use WTFURL in place of GoogleURL.
>>
>> I still think it is a bit backwards for Chromium's network stack to depend
>> on WebKit,
>> but I remain open minded about this.  I'm curious how it will work out.
>
> The general approach I had in mind was to view WTFURL as a separate
> library that just happens to be hosted at svn.webkit.org.  That
> requires some careful managing of dependencies but it seems worth
> trying.

I don't really want to reopen this debate, but how is that different
than checking GoogleURL into webkit? Maciej was saying that this would
impose an unacceptable burden on WebKit developers. I'm wondering what
his specific complaints about burden are and whether they might also
apply to a standalone WTFURL class.

For example, if Maciej is concerned about coding style, we can easily
fix that either way and it's a non-issue. If the concern is
familiarity, I'm not sure I see the difference between "Adam
reimplementing WTFURL" and "using some existing code" since they're
both "new code" from the perspective of average WebKit contributors.

I'm asking because I suspect Maciej's main concern is control over the
library and dependencies and the ability to easily make changes
necessary for Apple and WebKit (I would be worried about this, too).
>From my perspective, however, this might imply that he would want the
ability in the future to make modifications and add dependencies that
would be nonstarters with respect to Chromium's requirements. The
normal answer (which I agree with) when some random port wants to do
something weird and be able to compile without, for example,
JavaScript, is that "WebKit doesn't support these one-off use cases,
take the whole thing" and we should agree that this reasoning wouldn't
apply to dependencies on the URL component.

I think there was some agreement last year when the first part of this
project happened. If we restart it, I would want to again make sure
that everybody really understands what our dependency requirements are
and agree that we're not going to be changing them because it's better
for the "WebKit community" (c.f. Joe Mason's request to use all of
WTF). I also worry that this will be a 9 month project for Adam, as
the current partially done parsing thing took longer than anybody
would have liked. Personally I would prefer Adam spend time fixing my
security bugs :) So I want to be explicit on what Apple perceives as
the benefit of "Adam writes a bunch of new well-tested code with no
dependencies" vs. "copy existing well-tested code with no dependencies
into third_party and possibly reformat" so we can make sure there are
no surprises later.

That said, I am quite supportive of you unification work for the
benefit of WebKit!

Brett