Why is ResourceHandle.cpp in WebKit/chromium/src
In investigating the loader, I noticed that Chromium's ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a WebCore/platform abstract. Most of the other implementations of ResourceHandle are in WebCore/platform/mumble/ResourceHandleMumble.cpp. Is there a reason why Chromium uses a different design? Normally, we need a use a virtual function to jump from WebCore to WebKit/chromium. It looks like we're avoiding that in this case, at the cost of blurring the layer boundaries. Adam
We use this pattern a lot. You can see that ResourceHandle is implemented in terms of WebKit API (WebURLLoader). The alternative is to introduce extra interfaces between WebCore and WebKit. That has the benefit of isolating WebCore as you say, but it adds the cost of more layering and more indirection. We already have a lot of layering and indirection when you consider what lives on the other side of the WebKit API (in the Chromium repository). One small thing I have wanted to see done is to move all such classes to a special subdirectory of WebKit/chromium/src to make it clearer that they are in this special category. I've noticed that other ports that have their ResourceHandle implementation in WebCore/platform resort to using WebKit level classes and interfaces directly to achieve a similar effect. Doing so has similar abstraction-breaking issues. With the advent of WebKit2, there was a discussion about this topic as well. The desire for WebKit2 to support WebCore being built as a separate DSO was one of the primary reasons given for adding the extra layer of indirection between WebCore and WebKit for platform level things. (It has been a non-goal of the Chromium port to build WebCore as a separate DSO.) There are a lot more interfaces that would be needed besides just ResourceHandle{Client}. At last count it was fairly substantial. It would be good to take stock of the entire set before considering a change. -Darin On Fri, Sep 10, 2010 at 5:41 PM, Adam Barth <abarth@webkit.org> wrote:
In investigating the loader, I noticed that Chromium's ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a WebCore/platform abstract. Most of the other implementations of ResourceHandle are in WebCore/platform/mumble/ResourceHandleMumble.cpp.
Is there a reason why Chromium uses a different design? Normally, we need a use a virtual function to jump from WebCore to WebKit/chromium. It looks like we're avoiding that in this case, at the cost of blurring the layer boundaries.
Adam
That makes a certain amount of sense. It seems like we have three ways for WebCore to talk to Webkit/foo: 1) Client interfaces 2) PlatformBridge 3) Header-in-WebCore, implementation-in-WebKit/foo Is there some systematic way of determining which way we should use in a given circumstance? If we like pattern (3), maybe we should replace PlatformBridge with (3)? I think there was some talk earlier of WebKit2 using something called a "strategy," which seemed a bit like (2), but maybe more modular. To be clear, this came up in my trying to wrap my mine around the loader. I'm not sure there's anything wrong with (3), it just took me a while to find Chromium's implementation of ResourceHandle because it wasn't where I expected it to be. Adam On Fri, Sep 10, 2010 at 11:24 PM, Darin Fisher <darin@chromium.org> wrote:
We use this pattern a lot. You can see that ResourceHandle is implemented in terms of WebKit API (WebURLLoader). The alternative is to introduce extra interfaces between WebCore and WebKit. That has the benefit of isolating WebCore as you say, but it adds the cost of more layering and more indirection. We already have a lot of layering and indirection when you consider what lives on the other side of the WebKit API (in the Chromium repository). One small thing I have wanted to see done is to move all such classes to a special subdirectory of WebKit/chromium/src to make it clearer that they are in this special category. I've noticed that other ports that have their ResourceHandle implementation in WebCore/platform resort to using WebKit level classes and interfaces directly to achieve a similar effect. Doing so has similar abstraction-breaking issues. With the advent of WebKit2, there was a discussion about this topic as well. The desire for WebKit2 to support WebCore being built as a separate DSO was one of the primary reasons given for adding the extra layer of indirection between WebCore and WebKit for platform level things. (It has been a non-goal of the Chromium port to build WebCore as a separate DSO.) There are a lot more interfaces that would be needed besides just ResourceHandle{Client}. At last count it was fairly substantial. It would be good to take stock of the entire set before considering a change. -Darin
On Fri, Sep 10, 2010 at 5:41 PM, Adam Barth <abarth@webkit.org> wrote:
In investigating the loader, I noticed that Chromium's ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a WebCore/platform abstract. Most of the other implementations of ResourceHandle are in WebCore/platform/mumble/ResourceHandleMumble.cpp.
Is there a reason why Chromium uses a different design? Normally, we need a use a virtual function to jump from WebCore to WebKit/chromium. It looks like we're avoiding that in this case, at the cost of blurring the layer boundaries.
Adam
On Sep 11, 2010, at 2:49 AM, Adam Barth wrote:
That makes a certain amount of sense. It seems like we have three ways for WebCore to talk to Webkit/foo:
1) Client interfaces 2) PlatformBridge 3) Header-in-WebCore, implementation-in-WebKit/foo
Is there some systematic way of determining which way we should use in a given circumstance? If we like pattern (3), maybe we should replace PlatformBridge with (3)? I think there was some talk earlier of WebKit2 using something called a "strategy," which seemed a bit like (2), but maybe more modular.
To be clear, this came up in my trying to wrap my mine around the loader. I'm not sure there's anything wrong with (3), it just took me a while to find Chromium's implementation of ResourceHandle because it wasn't where I expected it to be.
We have a start on the strategy pattern, you can see it in: WebCore/platform/PlatformStrategies.h WebProcess/WebCoreSupport/WebPlatformStrategies.cpp WebKit/mac/WebCoreSupport/WebPlatformStrategies.mm WebKit/win/WebCoreSupport/WebPlatformStrategies.cpp The "strategy" pattern is intended for cases where the implementation of something in WebCore is to be "virtualized" up to the WebKit layer, including the possibility of switching at runtime, but it's expected to be a global switch for that particular instance of WebCore, not per-object. Client interfaces, on the other hand, are intended as callback interfaces for code that is logically "on top of" WebCore, to provide notifications and the opportunity for policy-type decisions. I think the modular Strategy pattern is better than the monolithic Bridge pattern. Way back in the day we used to have a single WebCoreBridge as the interface between WebCore and WebKit. We moved away from that design because it was messy and the bridge had a tendency to become a god object over time. Our bridge was also a two-way bridge (various methods implemented on each side) which I think is not the case with the chromium bridge. Regards, Maciej
On Sat, Sep 11, 2010 at 2:49 AM, Adam Barth <abarth@webkit.org> wrote:
That makes a certain amount of sense. It seems like we have three ways for WebCore to talk to Webkit/foo:
1) Client interfaces 2) PlatformBridge 3) Header-in-WebCore, implementation-in-WebKit/foo
Is there some systematic way of determining which way we should use in a given circumstance?
Good question. Historically, we started off using #2 exclusively, except for ResourceHandle. There was probably not a good reason for ResourceHandle being different at the time. PlatformBridge (previously named ChromiumBridge) was invented to help solve the very problem that led you here. I wanted us to have all WebCore symbols (except for the ChromiumBridge symbols) defined in WebCore. This way if you found something implemented in terms of ChromiumBridge functions, you would know to follow the trail to the WebKit layer's ChromiumBridge implementation. ChromiumBridge was to be the enumeration of the WebCore symbols left undefined by WebCore. One issue with ChromiumBridge is that people are forced to replicate functions on ChromiumBridge that correspond to other WebCore/platform class methods (e.g., see PlatformScreenChromium.cpp). This is unfortunate and tedious for people. The ResourceHandle model was less work to implement and less work to maintain, so that model became popular. See WebKit/chromium/src/GraphicsContext3D.cpp for example!
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. I like low cost and easy to maintain solutions that are intuitive for developers. I think solution #3 as currently implemented suffers from not being intuitive. If we can fix that, then we should be good. -Darin
I think there was some talk earlier of WebKit2 using something called a "strategy," which seemed a bit like (2), but maybe more modular.
To be clear, this came up in my trying to wrap my mine around the loader. I'm not sure there's anything wrong with (3), it just took me a while to find Chromium's implementation of ResourceHandle because it wasn't where I expected it to be.
Adam
On Fri, Sep 10, 2010 at 11:24 PM, Darin Fisher <darin@chromium.org> wrote:
We use this pattern a lot. You can see that ResourceHandle is implemented in terms of WebKit API (WebURLLoader). The alternative is to introduce extra interfaces between WebCore and WebKit. That has the benefit of isolating WebCore as you say, but it adds the cost of more layering and more indirection. We already have a lot of layering and indirection when you consider what lives on the other side of the WebKit API (in the Chromium repository). One small thing I have wanted to see done is to move all such classes to a special subdirectory of WebKit/chromium/src to make it clearer that they are in this special category. I've noticed that other ports that have their ResourceHandle implementation in WebCore/platform resort to using WebKit level classes and interfaces directly to achieve a similar effect. Doing so has similar abstraction-breaking issues. With the advent of WebKit2, there was a discussion about this topic as well. The desire for WebKit2 to support WebCore being built as a separate DSO was one of the primary reasons given for adding the extra layer of indirection between WebCore and WebKit for platform level things. (It has been a non-goal of the Chromium port to build WebCore as a separate DSO.) There are a lot more interfaces that would be needed besides just ResourceHandle{Client}. At last count it was fairly substantial. It would be good to take stock of the entire set before considering a change. -Darin
On Fri, Sep 10, 2010 at 5:41 PM, Adam Barth <abarth@webkit.org> wrote:
In investigating the loader, I noticed that Chromium's ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a WebCore/platform abstract. Most of the other implementations of ResourceHandle are in WebCore/platform/mumble/ResourceHandleMumble.cpp.
Is there a reason why Chromium uses a different design? Normally, we need a use a virtual function to jump from WebCore to WebKit/chromium. It looks like we're avoiding that in this case, at the cost of blurring the layer boundaries.
Adam
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 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 <mailto: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
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
participants (4)
-
Adam Barth
-
Balazs Kelemen
-
Darin Fisher
-
Maciej Stachowiak