<div class="gmail_quote">On Thu, Jun 17, 2010 at 9:47 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;">
<div class="im"><br>
On Jun 16, 2010, at 8:34 PM, Darin Fisher wrote:<br>
<br>
&gt; Hi, this is of course a very interesting topic!<br>
&gt;<br>
<br>
</div>Yes, and I really appreciate your feedback on this!<br>
<div class="im"><br>
&gt; Some comments:<br>
&gt;<br>
&gt; 1- Why do you see the need for these interfaces to be virtual?  Will there be multiple implementations?<br>
&gt; Some possible answers that come to mind:<br>
&gt; 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.<br>
<br>
&gt; b) Just following the {Chrome,FrameLoader,*}Client convention.<br>
&gt; c) So that WebCore can still be built as a DLL/DYLIB.<br>
&gt;<br>
<br>
</div>Mostly a) and c). This is correct. For &quot;current&quot; WebKit, we won&#39;t have a proxy implementation, but for WebKit2 we will. We&#39;d like both of these WebKit frameworks to be able to use the same WebCore framework.<br>
</blockquote><div><br></div><div>Makes sense.  By the way, there are more modules other than WebCore/platform that will require this kind of separation.  WebCore/storage has several examples of this.  Jorlow already modified the LocalStorage implementation to support this kind of separation.  It&#39;d be nice if whatever model is adopted for WebCore/platform can also be applied to these other modules.  (Doesn&#39;t sound like it will be an issue.)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
&gt; 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.<br>

<br>
</div>These functions are virtual because they are intended to be implemented by WebKit. Also, none of these functions are really called that often (and if they ever are, we should consider caching the result or other performance fixes).<br>
</blockquote><div><br></div><div>It&#39;s not so much about performance.  There&#39;s a cognitive cost to having so many layers.  But, given (c) above, I understand that you really don&#39;t have a choice.  In contrast, the Chromium project doesn&#39;t build WebCore as a standalone DLL, so we don&#39;t have the same constraint.  I don&#39;t have a problem replacing ChromiumBridge / PlatformBridge with a virtual table (or a set of virtual tables) if that means that we can share more code with other ports.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
&gt;<br>
&gt; 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.<br>

<br>
</div>I definitely agree that we shouldn&#39;t just pile things on to these new classes. (I also don&#39;t see why the ChromeClientChromium functions couldn&#39;t be added to ChromeClient directly).<br></blockquote><div>
<br></div><div>I think they can be moved to ChromeClient.  ChromeClientChromium was created to avoid adding things to ChromeClient that were Chromium specific.  Maybe some of those things will no longer be Chromium specific going forward.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
&gt;<br>
&gt; 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.<br>

&gt;<br>
<br>
</div>As we move forward and get more and more of WebKit2 in place, this will definitely be something to think about.<br>
<br>
Thanks for your feedback!<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div><br></div><div>I&#39;d definitely like to see how we can work together on some of this stuff.  It will mean less disparity between our ports.</div>
<div><br></div><div>-Darin </div></div>