[webkit-dev] Thoughts on WebKit/WebCore refactoring

Maciej Stachowiak mjs at apple.com
Fri Dec 23 00:15:08 PST 2005

I'm doing work now to refactor WebKit and move more of the code down  
to WebCore to live in the portable layer. Here's some thoughts I had  
on the direction for this:

* KHTMLPart gets renamed to DocumentController. It no longer makes  
any attempt to match the original KHTMLPart API. This will be  
platform-independent controller logic. If WebCore ever runs on KDE  
again, then a new KHTMLPart would have to be written to provide KDE- 
specific API glue on top of DocumentController.

* Eventually every document may have a DocumentController, even  
viewless documents created through such means as XMLHttpRequest or  
the DOM createDocument call.

* For a top-level document attached to a view, there will be a  
PageController class. This is for things that make sense only at the  
top level in a context where you have a view.

* DocumentController will bridge to WebFrame. Either using a two-way  
bridge as currently, or possibly two classes, WebFrameBridge and  
DocumentControllerBridge. Or bridging may be so minimal that  
WebFrameBridge is not needed and instead WebFrame connects to generic  
callbacks on the DocumentControllerBridge. Alternately, WebFrame  
might connect directly to the C++ interface on DocumentController.

* PageController will bridge to WebView. Otherwise much as above.

Anyway, this is the general idea. I think things will gradually  
moving in this direction, and the loading and frame traversal logic  
will increasingly live in WebCore.

Any comments on the names or other aspects of this design?


More information about the webkit-dev mailing list