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