[webkit-dev] Changing the implementation of KURL

[Brett Wilson]

On Sat, Jan 28, 2012 at 4:48 PM, Brett Wilson <brettw at chromium.org> wrote:
> On Sat, Jan 28, 2012 at 4:07 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>> On Jan 28, 2012, at 9:24 AM, Brett Wilson wrote:
>>
>>> 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 don't think anyone is expecting to implement new URL code from scratch. The proposals that were put forward are, as I understand them:
>>
>> (1) Check in GoogleURL as-is into the ThirdParty directory as an external dependency; future maintenance would be done via the canonical GoogleURL repository.
>> (2) Check in GoogleURL as a proper part of WebKit, adapting its coding style and wrapping it in a way that works well with other WebKit/WTF data types.
>>
>> The issue is not new code or not, but the ability to maintain it going forward.
>
> That's great, thanks.
>
>>> 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).
>>
>> That's exactly it.
>>
>>> 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.
>>
>> I think that, at this point, Benjamin is volunteering to do the bulk of work and Adam is offering to help. The code would be more along the lines of reformatting and refactoring than "write[ing] a bunch of new code" as I understand it.
>>
>> I understand your concern about wanting to keept his code free of unwanted dependencies. However, we do already have a pretty hard boundary that WTF can't depend on anything higher in the stack. We could make WTFURL even more restricted if that was necessary or helpful. However, I think most of us who do not work on Chromium are not clear on what exactly the dependency constraints are. It would be helpful if you or Adam or someone else could document them.
>>
>> Let's take some specific examples. Would using WTF::Vector inside the implementation (not necessarily at the API boundary, just internally) be acceptable? Or would it be required to use C arrays or std::vector? Would using WTF's ASSERT family of macros be acceptable, or should some other form of asserts be used? The are examples I can think of where "dependencies" could simply be added in the course of trying to get the code to be in WebKit style.
>
> I'm not necessarily speaking for the network folks, but I would not
> want any WTF dependencies at all. The existing core code doesn't have
> any dependencies on STL, and even the ICU dependency (for IDN and
> query encoding) is optional. The library is used for some places where
> we want minimal code. For example, GoogleURL is Google's safe browsing
> URL canonicalizer which is used in a variety of contexts on the server
> and in client code. We need to be able to preserve these uses without
> linking in largish template libraries.
>
> The GURL class is written on top of this core library code and uses
> STL for convenience with the rest of Chromium code. Our KURL wrapper
> is also written on top of this core layer, so we don't have to do a
> WTF::String -> std::string conversion (which is obviously important
> for performance).

So to clarify, I think we need to keep the current architecture.
Obviously WebKit needs a URL class that uses its String class, so
WTFURL would probably be a wrapper around some core library for WebKit
to use. Chromium would rewrite our GURL class to use the same core
library and keep std::strings (we don't want all our browser-level
code to have to convert std::string -> WTF::String just like today we
don't want to do the inverse in WebKit).

Brett