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

[Gustavo Sverzut Barbieri]

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.

Hi Anders, after reading your mail and the whole thread I can confirm
EFL port agrees with that. I'm in the team of those that don't  care
much about name that will be used as none of them is clearly better,
but the shorter the better :-)

I'm quite glad the WebKit2 is progressing and already contributing to
the old core, surely it will help if we go to WebKit2.

BR,

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202