[webkit-dev] Long-term Google-URL integration plans

[Darin Fisher]

On Thu, Oct 2, 2008 at 6:40 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 2, 2008, at 6:26 PM, Peter Kasting wrote:
>
> The prospect of WTF types in general tends to make me leery, since using
> one can bring in dependencies on others, and we wouldn't want to bring more
> dependencies than necessary into the Chromium front-end code; but if this
> were confined to using existing lightweight WTF types that didn't depend on
> other types, for cases where the current low-level GURL code is already
> rolling its own types, then there's probably no loss to anyone by doing that
> (and a small gain for embedders already using WTF types).
>
>
> Yes, I can see that pulling in an open-ended set of dependencies would
> defeat the purpose of the exercise for you guys. I would not expect that to
> happen.
>


My main concern is that the code be parameterized (templatized) properly so
that we can use it with the data types that are compatible with Chromium
code (STL) as well as WebKit code (WTF).  I don't think it is desirable to
depend on WTF directly since that would introduce WTF types into elements of
Chromium that are otherwise quite divorced from WebKit (e.g., our network
stack).  This is why I told you that I supported a type neutral core w/
interfaces like KURL and GURL that cater to a particular choice of container
types.  I think if you study the code and our usage of the code in Chromium,
you will see that this is a reasonable requirement.

At this stage, I think it is difficult to know exactly what the proposed
code will look like.  However, IMO the general direction that we arrived at
is good since it is a path that will allow all WebKit-based products
(including Chrome!) to converge on a better solution for URL parsing and
canonicalization.

That said, I am on the same page as Brett.  In the short term, the #ifdef he
proposed is not going to be hard for us to maintain in the interim or
forever if we end up agreeing to disagree about the future of KURL.  We
really do not wish to burden anyone with having to maintain our #ifdefs (or
anything related to our port!), but a few #ifdefs can go a long way to
helping free us to work on more important WebKit issues.  We really abhor
#ifdefs, but sadly they are sometimes the best way.

We can also do a version of what Brett proposes without introducing any
#ifdefs if that would be preferrable.

#include "KURLPrivate.h"
class KURL {
 public:
  // interface methods
 private:
  KURLPrivate p;
};

If we then put KURLPrivate.h into a subdirectory, it will be easy to change
that out at build time.  Bottom line: we don't want to cause existing WebKit
maintainers any extra headache here.

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/9832c149/attachment.html