Hi there Anders, I think this sounds pretty fine at least from a Qt perspective; and it will also easily enable us to let some of our platforms override the implementation using a plugin system. We already have such a system in place (PlatformPlugin) so that platforms can re-implement the handling of select popups, notifications etc. I think this new system will make it a lot easier to extend this to other areas, as needed.
Cheers, Kenneth On Wed, Jun 16, 2010 at 9:30 PM, Anders Carlsson <[email protected]> wrote: > Hi everyone, > > We've now reached the point in WebKit2 development where we need to be able > to override some global calls in WebCore so that we can funnel them through > to another process, in a similar way to what Chromium does. We also need to > be able to override the calls at run-time, so that we can use the same > WebCore framework with both current WebKit and WebKit2. > > Here's a proposal for something I call "Platform mechanisms" that I hope can > be used by other ports as well as replacing the Chromium bridge long term: > > The design pattern we use in WebCore for when a port wants to override > functionality is the "abstract client class" pattern. We have a > FrameLoaderClient per frame, a ChromeClient per Page etc. Some functionality > is global, and doesn't really belong to a specific object, for example: > > * Clipboard handling > * File access > * Plug-ins. > > I propose that we create an abstract class, "PlatformMechanism" which acts as > the starting point for accessing such functionality, something like: > > class PlatformMechanism { > virtual ClipboardMechanism* clipboardMechanism() = 0; > virtual FileAccessMechanism* fileAccessMechanism() = 0; > virtual PluginMechanism* pluginMechanism() = 0; > }; > > class PluginMechanism { > virtual void refreshPlugins() = 0; > virtual void getPluginInfo(Vector<PluginInfo>&) = 0; > }; > > The various ports would subclass PlatformMechanism, implement the various > mechanism classes and then call into WebCore to set the PlatformMechanism. > This approach gives a natural separation of the functionality. (There's of > course nothing stopping you from having a single class inherit from all of > the mechanism classes). We could also consider adding some functions to > PlatformMechanism directly, for example if a mechanism class would end up > with just a single function. > > The advantage of having a single "PlatformMechanism" aggregator class is that > we don't need lots of setFooMechanism calls that ports would need, and if > someone adds a new mechanism class, ports will fail to build instead of > mysteriously crash when it turns out someone has forgotten to add a call to > set the mechanism. > > We would also provide WebCore implementations of the various mechanisms, so > that ports that don't want to override anything would just return the WebCore > mechanisms. We could even have a WebCorePlatformMechanism class that you > could set as the default class. This would enable ports to pick where WebCore > should be used. > > I would very much appreciate any comments on this, and if I don't hear any > major objections I will start landing parts of this, conditionally compiled > by a WTF_USE_PLATFORM_MECHANISM define that's turned on for Mac WebKit. > > Thanks, > Anders > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
