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

[Balazs Kelemen]

On 06/17/2010 02:30 AM, 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;
> };
>
> 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. 
>
>   

   Hi everyone!

I want to share you my toughts about WebKit2 and the PlatformStrategies
abstraction.
I am working on the Qt port of WebKit2. Currently I have a crash in
PluginData::initPlugins in PluginDataQt.cpp where we want to downcast
the ChromeClient to it's Qt derivate (ChromeClientQt) and access to the
Qt API specific page class (QWebPage):

|QWebPage* webPage = static_cast(m_page->chrome()->client())->m_webPage;|

Of course the ChromeClient is not a ChromeClientQt so we are crashing
there. I am thinking about using the platform strategies to solve this
but my problem is that plugin handling in Qt is bounded to the page. The
Qt API-s has a "QWebPage::setPluginFactory" method so the initPlugins
should take care about the page specific settings. This is in contrast
with the idea behind the PluginStrategy abstraction.
There are other similar situations where we want to access the port
specific client object. One is in ResourceHandleQt.cpp:

|getInternal()->m_frame =
static_cast(frame->loader()->client())->webFrame();|

This one is also crashing in WebKit2. Hopefully this one can be fixed by
the work tracked in https://bugs.webkit.org/show_bug.cgi?id=42292.
<https://bugs.webkit.org/show_bug.cgi?id=42292>
I do not want to implement this features in the WebKit2 port for now but
I need a way to disable them in runtime. I am afraid that neither the
abstract client class shame nor the strategy provides an elegant way to
achieve this.
One idea came to my mind is to extend the concrete port specific
Strategy classes with methods like "isPluginFactorySupported" and ask it
in WebCore. In this case we would downcast the Strategy object to it's
concrete type in WebCore what is not an elegant thing. Do you think it
is acceptable?

I am absolutely open for your suggestions.

Cheers!
Balazs Kelemen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100817/f83409f1/attachment.html>