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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
