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

[Darin Fisher]

Hi, this is of course a very interesting topic!

Some comments:

1- Why do you see the need for these interfaces to be virtual?  Will there
be multiple implementations?
Some possible answers that come to mind:
a) Yes, there could be a proxy implementation used to marshal calls to the
"real" implementation that lives in the main process.  Both should implement
the same interface.
b) Just following the {Chrome,FrameLoader,*}Client convention.
c) So that WebCore can still be built as a DLL/DYLIB.

2- This looks a lot like WebKitClient in the Chromium WebKit API, except
that WebKitClient is defined at the API layer and not at the
WebCore/platform layer.  Related point:  WebCore::ChromiumBridge is just a
bunch of static functions because it seems wasteful to define intermediate
virtual functions at the WebCore level.  Note:  There is a plan to rename
ChromiumBridge to PlatformBridge because the Android port wishes to share
some of the same infrastructure.  There is already a typedef in place.

3- Not all of the WebCore/platform classes are well suited for a
straightforward delegation.  In some cases, delegation back through
ChromeClient is actually better.  See the extra methods on
ChromeClientChromium, which extends ChromeClient.  I believe that at least a
few methods on ChromiumBridge should be re-routed in this manner.

4- There are numerous concrete types (e.g., for cursors, icons, images,
etc.) that end up being defined very differently at the port layer for a
multi-process port.  This may be a non-factor though, but perhaps we should
think about how to share these definitions too.

Thanks for working on this!
-Darin


On Thu, Jun 17, 2010 at 12:30 AM, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100617/278bfa4f/attachment.html>