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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 1 23:45:08 PDT 2009


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





------- Comment #10 from sam at webkit.org  2009-07-01 23:45 PDT -------
(In reply to comment #8)
> > 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.
> 

While this bug is probably the wrong venue to have this discussion, I do want
to state that I don't think ports making different architectural decisions is
good idea for the health of the project.  It is something I seriously object
to.  In previous discussions with members of the Chromium team it has been
indicated that the bridge was a temporary measure and the existing forms of
abstraction would be adopted and extended where necessary (glue on the bottom
in WebCore/platform/ and glue on top in the form of client interfaces).  


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