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
