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@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