I've been studying the various objects related to loading frames, and I wanted to get feedback on the below proposal before making a bunch of changes. There seem to be three main objects related to the loading state for a frame:
* MainResourceLoader. MainResourceLoader inherits from ResourceLoader and receive callbacks from the network stack. It's primary task is to take callbacks from the network stack and route them to the appropriate higher-level APIs. Currently, MainResourceLoader is also concerned with navigation policies, but I'm not sure if that's correct. * DocumentLoader. DocumentLoader is responsible for all the document-specific loading state. For example, the DocumentLoader should know if we've received any data for this document yet and should be in charge of actually stuffing the received data into the Document. (Both of these examples are currently done by FrameLoader.) * FrameLoader. FrameLoader is responsible for the frame-level loading state. Essentially, the FrameLoader's job is to determine the disposition of load requests and shepherd DocumentLoaders through the policy / provisional / committed states. The FrameLoader goes through the following process: 1) Dispatch. A load request enters the machine. a) The request is routed to the appropriate frame. b) If the request should generate a fragment scroll, scroll the view and exit the machine. c) Otherwise, create a DocumentLoader to encapsulate the load state for this request. 2) Policy Check. Ask the FrameLoaderClient's policy interface whether the embedder actually wants to go through with the load and wait for a response. 3) Provisional. Once we get the go-ahead from the client, we actually start generating a network request (i.e., create MainResourceLoader). In this phase, we receive redirects and headers, and eventually decide whether to commit the load. 4) Committed. We've decided to actually navigate the frame. a) Detach the old document from the frame. b) Attach the new document to the frame. In addition to shifting a bunch of the document-specific loading state from FrameLoader to DocumentLoader, I think we should create two new objects: A) FrameNavigator. This object would handle the dispatching phase above. The goal of creating this object is to let FrameLoader focus on load requests that will actually result in network / cache traffic. B) LoadObserver. Currently ResourceLoader forwards many of the network stack callbacks (e.g., ResourceLoader::didReceiveResponse) to FrameLoader so they can be farmed out to the Web Inspector, ProgressTracker, FrameLoaderClient, and others. The goal of this object is to remove that complexity from FrameLoader. Let me know if you have any comments or suggestions. Thanks, Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
