I have no strong opinion about which pattern should we use but I think we should decide which is the preferred in a given type of WebKit - WebCore interaction. Currently we have introduced a new pattern with the NetworkingContext. Shouldn't we rework that and implement in the form of a strategy? Maybe it could be a good way of testing the usability of the strategy pattern. Currently I would like to remove the frame dependency in the qt version of PluginData (because it is crashing with WebKit2) and I am wondering about should I use the strategy pattern or should I introduce a PluginContext abstraction.

On 09/12/2010 08:39 AM, Maciej Stachowiak wrote:

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

On Sat, Sep 11, 2010 at 2:49 AM, Adam Barth <abarth@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


_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev