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

[Adam Barth]

That makes a certain amount of sense.  It seems like we have three
ways for WebCore to talk to Webkit/foo:

1) Client interfaces
2) PlatformBridge
3) Header-in-WebCore, implementation-in-WebKit/foo

Is there some systematic way of determining which way we should use in
a given circumstance?  If we like pattern (3), maybe we should replace
PlatformBridge with (3)?  I think there was some talk earlier of
WebKit2 using something called a "strategy," which seemed a bit like
(2), but maybe more modular.

To be clear, this came up in my trying to wrap my mine around the
loader.  I'm not sure there's anything wrong with (3), it just took me
a while to find Chromium's implementation of ResourceHandle because it
wasn't where I expected it to be.

Adam


On Fri, Sep 10, 2010 at 11:24 PM, Darin Fisher <darin at chromium.org> wrote:
> 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
>
>