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

[Darin Fisher]

On Thu, Jun 17, 2010 at 9:47 AM, Anders Carlsson <andersca at apple.com> wrote:

>
> 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.
>

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'd be nice if whatever model is
adopted for WebCore/platform can also be applied to these other modules.
 (Doesn't sound like it will be an issue.)



>
> > 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).
>

It's not so much about performance.  There's a cognitive cost to having so
many layers.  But, given (c) above, I understand that you really don't have
a choice.  In contrast, the Chromium project doesn't build WebCore as a
standalone DLL, so we don't have the same constraint.  I don'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.



>
> >
> > 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).
>

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.



>
> >
> > 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!
>
>
I'd definitely like to see how we can work together on some of this stuff.
 It will mean less disparity between our ports.

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