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

[Darin Fisher]

On Sat, Sep 11, 2010 at 11:39 PM, Maciej Stachowiak <mjs at 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 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
>
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100913/59f0e29c/attachment.html>