[Webkit-unassigned] [Bug 26905] Don't use PlatformMessagePortChannel in any files

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 1 21:43:13 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=26905


fishd at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at webkit.org




------- Comment #8 from fishd at chromium.org  2009-07-01 21:43 PDT -------
> WebCore classes should not depend on WebKit with the exception of client
> interfaces. If that does happen, that is considered a layering violation.

The Chromium port works differently to help avoid an extraneous number of
interfaces (vtables) between WebKit and WebCore.  Instead, what we do is
specify a set of 'undefined' functions (see ChromiumBridge) and sometimes
'undefined' classes (ResourceHandle is a good example) that are left to the
WebKit layer to define.  In the WebKit layer, those undefined WebCore symbols
and classes are implemented in terms of WebKit API interfaces (vtables).  Note:
This WebKit API I speak of is the Chromium WebKit API, which is still brewing
in the Chromium repository (soon to be upstreamed to svn.webkit.org; see my
post to webkit-dev if you are interested).  Since only the Chromium port has
need to route such things up through WebKit, this helps keep WebCore simple,
while keeping the set of dependencies reasonably well scoped.

If you think about it, this is actually very similar to the
WebKitSystemInterface approach that PLATFORM(MAC) uses.  That encapsulates the
set of additional dependencies required by the PLATFORM(MAC) port of WebCore. 
In Chromium's case, we preferred to bridge up to the embedder instead of having
the embedder also provide support below WebCore.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list