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

[Maciej Stachowiak]

On Sep 11, 2010, at 9:42 PM, Darin Fisher wrote:

> On Sat, Sep 11, 2010 at 2:49 AM, Adam Barth <abarth at webkit.org> wrote:
> 
>  If we like pattern (3), maybe we should replace
> PlatformBridge with (3)?
> 
> Yes, perhaps we should do that.  In concert with that, it would be good to create a subdirectory in WebKit/chromium/src for these WebCore class implementations.
> 
> I'm concerned that the PlatformStrategies approach adds too much maintenance overhead given the number of interfaces we'd need to add to it.

Is it really more maintenance than PlatformBridge? That class includes effectively a bunch of interfaces, they are just demarcated with comments instead of actually being separate classes. Modularity is good. Large interfaces that are a grab-bag of different things are not good for maintainability in the long run. At least that is what we learned from WebCoreBridge back in the day.

Furthermore, the PlatformBridge solution is one we cannot use for WebKit2. It uses static methods exclusively and so forces the binding to be compile-time. But we'd like to be able to use the same copy of WebCore with an in-process implementation and an out-of-process one, for many things. Thus, we will need the PlatformStrategies approach for a number of things. For the same reason, header-in-WebCore-implementation-in-WebKit won't work. Chromium could choose to handle the delegation of those things in a completely different way, but that won't lower complexity for the project as a whole. 

Can you give a bit more detail on why the PlatformStrategies approach seems like too much maintenance overhead to you? I would prefer as much as possible to have an approach that works for all ports. In particular, I hope that with WebKit2 having many of the same specialized requirements as Chromium, we can reduce the amount of Chromium-specific pieces of architecture and find more general solutions to these problems.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100911/66e6c26b/attachment.html>