[webkit-dev] A proposal for "Platform Mechanisms"

[Kenneth Christiansen]

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 <andersca at apple.com> 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
> webkit-dev at lists.webkit.org
> 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