On Jun 16, 2010, at 8:34 PM, Darin Fisher wrote:
> Hi, this is of course a very interesting topic!
>
Yes, and I really appreciate your feedback on this!
> 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.
>
Mostly a) and c). This is correct. For "current" WebKit, we won't have a proxy
implementation, but for WebKit2 we will. We'd like both of these WebKit
frameworks to be able to use the same WebCore framework.
> 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.
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).
>
> 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.
I definitely agree that we shouldn't just pile things on to these new classes.
(I also don't see why the ChromeClientChromium functions couldn't be added to
ChromeClient directly).
>
> 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.
>
As we move forward and get more and more of WebKit2 in place, this will
definitely be something to think about.
Thanks for your feedback!
- Anders
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
