Hi, this is of course a very interesting topic!<div><br></div><div>Some comments:</div><div><br></div><div>1- Why do you see the need for these interfaces to be virtual?  Will there be multiple implementations?</div><div>Some possible answers that come to mind:</div>
<div>a) Yes, there could be a proxy implementation used to marshal calls to the &quot;real&quot; implementation that lives in the main process.  Both should implement the same interface.</div><div>b) Just following the {Chrome,FrameLoader,*}Client convention.</div>
<div>c) So that WebCore can still be built as a DLL/DYLIB.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks for working on this!</div><div>-Darin</div><div><br><br><div class="gmail_quote">On Thu, Jun 17, 2010 at 12:30 AM, Anders Carlsson <span dir="ltr">&lt;<a href="mailto:andersca@apple.com">andersca@apple.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi everyone,<br>
<br>
We&#39;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.<br>

<br>
Here&#39;s a proposal for something I call &quot;Platform mechanisms&quot; that I hope can be used by other ports as well as replacing the Chromium bridge long term:<br>
<br>
The design pattern we use in WebCore for when a port wants to override functionality is the &quot;abstract client class&quot; pattern. We have a FrameLoaderClient per frame, a ChromeClient per Page etc. Some functionality is global, and doesn&#39;t really belong to a specific object, for example:<br>

<br>
* Clipboard handling<br>
* File access<br>
* Plug-ins.<br>
<br>
I propose that we create an abstract class, &quot;PlatformMechanism&quot; which acts as the starting point for accessing such functionality, something like:<br>
<br>
class PlatformMechanism {<br>
 virtual ClipboardMechanism* clipboardMechanism() = 0;<br>
 virtual FileAccessMechanism* fileAccessMechanism() = 0;<br>
 virtual PluginMechanism* pluginMechanism() = 0;<br>
};<br>
<br>
class PluginMechanism {<br>
   virtual void refreshPlugins() = 0;<br>
   virtual void getPluginInfo(Vector&lt;PluginInfo&gt;&amp;) = 0;<br>
};<br>
<br>
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&#39;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.<br>

<br>
The advantage of having a single &quot;PlatformMechanism&quot; aggregator class is that we don&#39;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.<br>

<br>
We would also provide WebCore implementations of the various mechanisms, so that ports that don&#39;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.<br>

<br>
I would very much appreciate any comments on this, and if I don&#39;t hear any major objections I will start landing parts of this, conditionally compiled by a WTF_USE_PLATFORM_MECHANISM define that&#39;s turned on for Mac WebKit.<br>

<br>
Thanks,<br>
Anders<br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a></blockquote></div></div>