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

[Balazs Kelemen]

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 at webkit.org
>> <mailto: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
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>   

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