On Sat, Jan 28, 2012 at 4:48 PM, Brett Wilson <bre...@chromium.org> wrote: > On Sat, Jan 28, 2012 at 4:07 PM, Maciej Stachowiak <m...@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 <aba...@webkit.org> wrote: >>>> On Fri, Jan 27, 2012 at 9:44 PM, Darin Fisher <da...@chromium.org> wrote: >>>>> On Fri, Jan 27, 2012 at 2:39 AM, Adam Barth <aba...@webkit.org> wrote: >>>>>> On Fri, Jan 27, 2012 at 1:49 AM, Maciej Stachowiak <m...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
