On Oct 13, 2009, at 10:50 AM, Adam Barth wrote:
* 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.
I don’t think it’s right that the code to deal with content policy is
in MainResourceLoader. I think that code belongs in DocumentLoader or
FrameLoader instead.
* 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.)
That sounds right. Much of the code currently in FrameLoader should go
into DocumentLoader. Anything about a single document and not about
transitions between documents should go there.
* 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.
Yes, that sounds good.
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.
I don’t know that I would call this “Dispatch” — I suppose the frame
routing part is good here. I am also not certain that all of the frame
routing can be done at this point.
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.
Some policy checks do happen at this point. But note that there are
other policy checks that occur later. For example, the content policy
can’t be checked until we receive data from the network.
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.
There are content policy checks here.
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.
This seems like a good idea, but I think the boundary will be tricky.
For example, is detecting when a page load is complete including
subresources something the frame navigator would be responsible for or
the loader? What about loading from the back/forward cache as opposed
to the network?
A list of what functions and data would go in each class might help me
understand if this refactoring is good.
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.
There is a distinction between resource load client calls and higher
level load client calls. The resource load client calls are the ones
that use a request identifier. And these are indeed all about the
resource loader.
But many other client calls do not involve the resource loader
directly. If you don’t plan to make the LoadObserver responsible for
these, then I think it should probably be called the
ResourceLoadObserver, since it observes the lower level loading of
resources but not the higher level loading of web pages.
I’m also not entirely sure if “observer” is the right name here, but I
have nothing better to suggest at this time.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
