On Thu, Oct 2, 2008 at 3:43 PM, David Hyatt <[EMAIL PROTECTED]> 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. > 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev