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