[webkit-dev] Thoughts on WebKit/WebCore refactoring
sullivan at apple.com
Fri Dec 23 07:24:05 PST 2005
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
> * 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.
More information about the webkit-dev