[webkit-dev] Why is ResourceHandle.cpp in WebKit/chromium/src

[Darin Fisher]

We use this pattern a lot.  You can see that ResourceHandle is implemented
in terms of WebKit API (WebURLLoader).

The alternative is to introduce extra interfaces between WebCore and WebKit.
 That has the benefit of isolating WebCore as you say, but it adds the cost
of more layering and more indirection.  We already have a lot of layering
and indirection when you consider what lives on the other side of the WebKit
API (in the Chromium repository).

One small thing I have wanted to see done is to move all such classes to a
special subdirectory of WebKit/chromium/src to make it clearer that they are
in this special category.

I've noticed that other ports that have their ResourceHandle implementation
in WebCore/platform resort to using WebKit level classes and interfaces
directly to achieve a similar effect.  Doing so has similar
abstraction-breaking issues.

With the advent of WebKit2, there was a discussion about this topic as well.
 The desire for WebKit2 to support WebCore being built as a separate DSO was
one of the primary reasons given for adding the extra layer of indirection
between WebCore and WebKit for platform level things.  (It has been a
non-goal of the Chromium port to build WebCore as a separate DSO.)

There are a lot more interfaces that would be needed besides just
ResourceHandle{Client}.  At last count it was fairly substantial.  It would
be good to take stock of the entire set before considering a change.

-Darin


On Fri, Sep 10, 2010 at 5:41 PM, Adam Barth <abarth at webkit.org> wrote:

> In investigating the loader, I noticed that Chromium's
> ResourceHandle.cpp is in WebKit/chromium/src.  ResourceHandle is a
> WebCore/platform abstract.  Most of the other implementations of
> ResourceHandle are in
> WebCore/platform/mumble/ResourceHandleMumble.cpp.
>
> Is there a reason why Chromium uses a different design?  Normally, we
> need a use a virtual function to jump from WebCore to WebKit/chromium.
>  It looks like we're avoiding that in this case, at the cost of
> blurring the layer boundaries.
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100910/398fe3f3/attachment.html>