[webkit-dev] Thoughts on WebKit/WebCore refactoring

[John Sullivan]

On Dec 23, 2005, at 12:15 AM, Maciej Stachowiak wrote:

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

"DocumentController" seems like a problematic name because it's too  
close to NSDocumentController, yet it's very much not parallel.  
Safari has one NSDocumentController per window, but there's one  
DocumentController per web frame.

John