On Sat, Jan 28, 2012 at 5:51 PM, Benjamin Poulain <[email protected]> wrote: > On Sat, Jan 28, 2012 at 4:59 PM, Brett Wilson <[email protected]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
