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

[Simon Fraser]

On Jun 16, 2010, at 5:30 PM, Anders Carlsson 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;
> };

I don't think having "mechanism" in all the names here really adds much. Other than letting me know that these classes are all for some kind of port-specific specialization, it doesn't communicate anything about what they do. Maybe "handler" would be a slightly better word to use?

Also, PlatformMechanism is a Factory, and should be named accordingly. Or maybe it's a Source of clients/mechanisms.

Do these calls return a new instance each time, or a singleton, or does it not matter?

These feel like the OOP equivalent of ChromeClient; can we use that to inform naming?

> 
> 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.

Similar to EmptyChromeClients?

Simon