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

[Maciej Stachowiak]

On Sep 11, 2010, at 2:49 AM, Adam Barth wrote:

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

We have a start on the strategy pattern, you can see it in: 

WebCore/platform/PlatformStrategies.h
WebProcess/WebCoreSupport/WebPlatformStrategies.cpp
WebKit/mac/WebCoreSupport/WebPlatformStrategies.mm
WebKit/win/WebCoreSupport/WebPlatformStrategies.cpp

The "strategy" pattern is intended for cases where the implementation of something in WebCore is to be "virtualized" up to the WebKit layer, including the possibility of switching at runtime, but it's expected to be a global switch for that particular instance of WebCore, not per-object.

Client interfaces, on the other hand, are intended as callback interfaces for code that is logically "on top of" WebCore, to provide notifications and the opportunity for policy-type decisions.

I think the modular Strategy pattern is better than the monolithic Bridge pattern. Way back in the day we used to have a single WebCoreBridge as the interface between WebCore and WebKit. We moved away from that design because it was messy and the bridge had a tendency to become a god object over time. Our bridge was also a two-way bridge (various methods implemented on each side) which I think is not the case with the chromium bridge.

Regards,
Maciej