[webkit-dev] Use of Frame by ResourceHandle

[Adam Barth]

On Sat, Sep 11, 2010 at 8:15 AM, Holger Freyther <zecke at selfish.org> 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