[webkit-dev] loader refactoring plan

[Maciej Stachowiak]

Hi everyone,

As you may know, a number of us have been tearing apart the WebKit  
loader-related code to make it simpler and more portable. I decided I  
should post a few more details of the ongoing refactoring plan. For  
starters, let me give a brief overview of how loading worked in  
WebKit prior to all the refactoring work, for a few different  
scenarios. These diagrams are oversimplified but should give the  
basic idea. Apologies for the HTML formatting of this message but I  
wanted to make sure the ASCII art came out right.

Main resource loaded, started from app via API:

[ WebFrame ] (ObjC, WebKit)
[ WebDataSource ] (ObjC, WebKit)
[ WebMainResourceLoader ] (ObjC, WebKit)
[ WebFrameBridge ] (ObjC, WebKit)
[ WebCoreFrameBridge ] (ObjC, WebCore)
[ FrameMac ] (C++, WebCore)
[ Frame ] (C++, WebCore)

Main resource loaded, started from engine via link click or form  
submission:

[ Frame ] (C++, WebCore)
[ FrameMac ] (C++, WebCore)
[ WebCoreFrameBridge ] (ObjC, WebCore)
[ WebFrameBridge ] (ObjC, WebKit)
[ WebFrame ] (ObjC, WebKit)
[ WebDataSource ] (ObjC, WebKit)
[ WebMainResourceLoader ] (ObjC, WebKit)
[ WebFrameBridge ] (ObjC, WebKit)
[ WebCoreFrameBridge ] (ObjC, WebCore)
[ FrameMac ] (C++, WebCore)
[ Frame ] (C++, WebCore)


Subresource load:

[ DocLoader ]  (C++, WebCore)
[ Cache ] (C++, WebCore)
[ Loader ] (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ WebCoreResourceLoaderImp ]
[ WebCoreFrameBridge ] (ObjC, WebCore)
[ WebFrameBridge ] (ObjC, WebKit)
[ WebFrame ] (ObjC, WebKit)
[ WebDataSource ] (ObjC, WebKit)
[ WebSubresourceLoader ] (ObjC, WebKit)
[ WebCoreResourceHandle ] (ObjC, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ Loader ] (C++, WebCore)
[ Cache ] (C++, WebCore)
[ CachedResource ] (C++ WebCore)


Notice how it all goes through a crazy number of layers, with crazy  
jumping back and forth between WebCore and WebKit. Also, much of the  
essential logic is in platform-specific Objective-C or Objective-C++  
code. Here is the new target design:


Main resource loaded, started from app via API:

[ WebFrame ] (ObjC, WebKit)
[ FrameLoader ] (C++, WebCore)  ---> [ FrameLoaderClient ] (C++  
abstract base class, implemented in webkit to deliver delegates)
[ DocumentLoader ] (C++, WebCore)
[ MainResourceLoader ]  (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore)


Main resource loaded, started from engine via link click or form  
submission:

[ FrameLoader ] (C++, WebCore)  ---> [ FrameLoaderClient ] (C++  
abstract base class, implemented in webkit to deliver delegates)
[ DocumentLoader ] (C++, WebCore)
[ MainResourceLoader ]  (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore)


Subresource load:

[ DocumentLoader ]  (C++, WebCore)
[ Cache ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore)  ---> [ FrameLoaderClient ] (C++  
abstract base class, implemented in webkit to deliver delegates)
[ SubresourceLoader ] (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ Cache ] (C++, WebCore)
[ CachedResource ] (C++ WebCore)


As you can see, there will be much fewer layers involved in most  
loads, and the vast majority of the logic will be cross-platform C++  
in WebCore. WebKit will be limited to channeling down API calls and  
channeling up delegate callbacks, since these are essential points of  
type and language translation.


Here's where we stand right now:

- All loading related code has been factored out of WebFrame and  
WebDataSource into WebFrameLoader and WebDocumentLoader.
- Dispatch of delegates is via WebFrameLoaderClient ObjC protocol  
declared in WebCore and implemented in WebKit
- All loader-related classes have been moved out of WebKit and into  
WebCore/loader/mac
- All loader-related code has been pulled out of WebFrameBridge and  
moved down to WebCoreFrameBridge


Here are some steps that remain:

- Move loading-related code from WebCoreFrameBridge to WebFrameLoader  
and collapse layers as necessary
- Move loading-related code from Frame and FrameMac to WebFrameLoader  
and collapse layers as necessary
- Convert loader/mac code from ObjC classes to C++ classes
- Make WebFrameLoaderClient a C++ abstract base class instead of an  
ObjC protocol
- Shuffle things around so that Frame owns a FrameLoader rather than  
the bridge owning it.
- Merge DocLoader with WebDocumentLoader
- Change loader/mac code to use WebCore types
- Build up ResourceLoader abstraction enough to support everything  
needed by the higher-level logic.

We're trying to do this stuff sort of in parallel. I am working on  
cleaning up and building out the ResourceLoader API. Here is a first- 
pass set of headers that show the planned interface for  
ResourceLoader, ResourceLoaderClient, ResourceRequest,  
ResourceResponse, and related classes:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: resource-api.zip
Type: application/zip
Size: 6494 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20061018/7f1835ce/resource-api.zip
-------------- next part --------------

Some details of this may change. I'm not sure CachedResourceResponse  
is a great name or fits so well in concept as it stands.

I am going to start by changing ResourceLoader to the new API, then  
ResourceLoader and ResourceLoaderClient are next, to be followed by  
addition of ResourceResponse. The more special-purpose types will  
come last. I'll also try to document this interface, since it is one  
of the main things platform porters will have to implement.

Regards,
Maciej