[webkit-dev] Changing the implementation of KURL

[Adam Barth]

On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain <benjamin at webkit.org> wrote:
> On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson <brettw at chromium.org> wrote:
>> 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).
>
> I don't really get this point. With WTF linked statically, no matter
> how "largish" WTF, it will not cost much to use.
>
> You say you don't want to convert std::string->WTF::String and
> WTF::String at the browser level, but aren't you doing that a lot more
> with the current code?
>
> Parsing valid URL can probably be done without WTF.
> URL canonicalization is frequent in WebKit and I would think using
> String directly is a good idea. Same for modifying a URL.

GURL abstracts the underlying storage so that the canonicalized URL is
written directly into the proper type.  As far as I can tell, there
isn't much advantage to WTFURL committing to a particular string type.

> Chromium is the only ports that use the same URL Class in the whole
> stack. And it seems you do not want any dependencies on WTF. Maybe an
> alternative is to change this and convert KURL->GoogleURL on platform
> boundaries like the other ports?

My guess is you won't be able to convince fishd to use different URL
libraries at different layers in Chromium.  There's a long history of
that causing security vulnerabilities, both in Firefox and in Safari.

Adam