On Sat, Sep 11, 2010 at 8:15 AM, Holger Freyther <[email protected]> wrote: > On 09/11/2010 05:57 PM, Adam Barth wrote: >> Do we still believe this FIXME is accurate? If so, I have some time >> next week to look at removing the dependency. There's a patch that >> either recently landed or is about to land that furthers the use of >> Frame by ResourceHandle, so I wanted to check with folks more broadly >> about whether this is the right direction. (Note that I haven't >> studied the code yet, so I'm not sure what would be required to remove >> the dependency.) > > I'am afraid QtWebKit is using that for a layering violation. Each QWebPage > (wrapper around WebCore::Page + FrameView) can have a separate network engine > (QNetworkAccessManager) and we go from WebCore::Frame to WebKit to find out > which engine to use.
How does Qt implement XMLHttpRequest from WebWorkers? Workers don't have a Frame to supply. SharedWorkers are even trickier... > I wonder how/if we can migrate that to a bridge, but I am afraid we will still > need to have some access to Document/Frame/Page. If we want to be able to use separate network backends for different Pages, perhaps we need some sort of PlatformNetworkHandle, which can be an opaque object (at least to WebCore) retrieved from the FrameLoaderClient. One of the benefits of removing Frame from the lower levels of the loader is that it prevents dependency inversions where objects lower down in the dependency chain use the Frame point to talk to objects higher up in the dependency chain. For example, until recently, the bytes destined for the main resource made several round-trips through the FrameLoader because each object that touched the bytes had a pointer to Frame and (for whatever reason) thought FrameLoader ought to be involved. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
