This will allow Chromium port's version to be implemented outside the WebKit repository. The reason to do this is so that our version can derive from classes that are in the Chromium repository.
Created attachment 32146 [details] Proposed patch
Seems kind strange. That will make it so that it's never possible to build a version of WebKit from the WebKit repository. That seems directly in contrast with historical goals...
Comment on attachment 32146 [details] Proposed patch > Index: WebCore/ChangeLog ... > + Reviewed by NOBODY (OOPS!). > + > + Small refactoring of MessagePortChannel so that a port's PlatformMessagePortChannel doesn't > + have to reside in the WebKit repository. I think it would be more accurate to say "so that PlatformMessagePortChannel may be defined at the WebKit layer" Otherwise, R=me
Wouldn't that be a layering violation? Or are you considering adding a client interface for that?
Created attachment 32166 [details] updated changelog
Eric: I'm not sure I understand your concern. If you're referring to someone just going to webkit.org and fetching/building, that'll work as before. I just moved some functions around. What I did is equivalent to how ResourceHandleInternal is declared in ResourceHandle.h but it's up to the port to define the class. Sam: not sure what you mean?
> Sam: not sure what you mean? WebCore classes should not depend on WebKit with the exception of client interfaces. If that does happen, that is considered a layering violation.
> 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.
Landed as: http://trac.webkit.org/changeset/45467
(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).