On Sat, Sep 11, 2010 at 11:39 PM, Maciej Stachowiak <mjs@apple.com> 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
I think it makes sense for the Chromium port to share the PlatformStrategies in use by WebKit2. I definitely prefer a world with fewer variations between the ports. That being said, I'm less sure if it makes sense for us to add a whole bunch of interfaces to PlatformStrategies that only Chromium will use. PlatformStrategies adds the overhead of defining an interface that is a replica of what we have to define at the WebKit API boundary. The advantage of defining ResourceHandle at the WebKit layer is that we can implement it in terms of WebKit API. That avoids an intermediate "platform strategy" interface that would be used to implement ResourceHandle. It means one less interface to maintain, which helps reduce maintenance and cognitive costs. The difference between PlatformStrategies and PlatformBridge is more subtle. In both cases, function signatures are replicated. However, in the PlatformBridge case there is no need to allocate an object to hold the replicated methods. Instead, the functions are static. This lends itself well for some use cases but not so well for others. At the end of the day, this is a small advantage. -Darin