[webkit-dev] Changing the implementation of KURL

[Maciej Stachowiak]

On Jan 27, 2012, at 12:22 AM, Darin Fisher wrote:

> On Fri, Jan 27, 2012 at 12:03 AM, Benjamin Poulain <benjamin at webkit.org> wrote:
> On Thu, Jan 26, 2012 at 11:17 PM, Darin Fisher <darin at chromium.org> wrote:
> > Instead of doing all of this work, have you considered just treating
> > GoogleURL in much the same way as WebKit treats ANGLE?  You could perhaps
> > just commit a copy of GoogleURL into Source/ThirdParty, and then WebKit as a
> > whole could switch to a consistent KURL implementation.
> 
> WTFURL is a copy of GoogleURL adapted to WebKit so I hope "it is not
> gonna be too much work" (tm). :)
> 
> As I understand, it was decided 2 years ago not to add GoogleURL into
> Source/ThirdParty to avoid pulling some dependencies and to have this
> important piece part of the WebKit project (I was not at that
> particular session).
> 
> Source/ThirdParty didn't exist until Aug 2010, when ANGLE was imported.  Before
> ThirdParty, there wasn't much of a convention of adding wholesale third-party libraries
> to WebKit.
> 
> There certainly was a decision made at the earlier WebKit summit to copy GoogleURL
> into WebKit, and massage it there as a path toward having only one KURL implementation.
> 
> My point was just that the work remaining to complete that effort isn't negligible.
> 
> Also, we seem to be successfully sharing ANGLE as-is, and that is also a very critical
> piece of software (impacting web browser security), so why not the same approach
> for the GoogleURL library?  I guess, I'm explicitly re-opening the conversation on this
> topic because it seems like the WTFURL approach will be a fair bit of work :-)

URL parsing is both much less code than ANGLE, and much more core to what a browser engine does. It's also code that exists in WebCore today, albeit in buggy form, while ANGLE provided something brand new. And finally, URL processing is performance-critical in ordinary page loading, while what ANGLE does is only relevant to WebGL performance. These seem like good reasons to have URL parsing code more integrated than the ThirdParty approach. URL parsing seems more like, say, CSS parsing or HTML parsing than like GL sanitization in this regard. I hope most would agree that replacing the CSS parser or the HTML parser with an external dependency would not be a good long-term move, even if the external component was initially less buggy.

While the proposed plan involves some effort up front, it seems less likely to create issues for non-Google contributors with a need to hack on URL processing in the future, as compared to the ThirdParty approach.

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.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120127/1228c4a9/attachment.html>