On Oct 2, 2008, at 2:53 PM, Darin Fisher wrote: > > I agree that it would be very nice to share implementations here. > > One thing I'd like to highlight: It is a requirement for Chromium > to use consistent URL parsing throughout the entire application. > This includes all processes, the network stack, etc. While we could > invoke KURL to do so, it is hugely beneficial to us to be able to > simply reuse the core elements of GoogleURL (url_canon, url_parse) > via the GURL interface. So, we end up with GKURL used by WebCore > and GURL used by the rest of Chromium, but both of those are just > thin interface layers around GoogleURL's core. I think it would be > very awkward (probably a non-starter) for us if we were not able to > separate the KURL interface from the guts and reuse those guts > efficiently in the other parts of our application. For example, > those guts are entirely parameterized the string type, allowing us > to substitute std::string for WebCore::String, and so on in a very > efficient manner. The core elements of GoogleURL do not depend on > any specific libraries, and that is very important for our reuse of > it throughout our entire application. > > Hope this helps clarify why we have what we have.
I'd be open to WebCore exporting a more general or lower-level URL interface that is more readily usable from non-WebCore contexts, if KURL does not suit as-is. I should also note that, originally, our KURL was a wrapper on top of NSURL, since the app level and network layer for the Mac port use NSURL. We decided to drop that in favor of cross-platform code, and convert to NSURL as the boundaries. As far as I know, we have not had serious problems from mismatches, whether security or otherwise. Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
