Re: [webkit-dev] Why is ResourceHandle.cpp in WebKit/chromium/src
We use this pattern a lot. You can see that ResourceHandle is implemented
in terms of WebKit API (WebURLLoader).
The alternative is to introduce extra interfaces between WebCore and WebKit.
That has the benefit of isolating WebCore as you say, but it adds the cost
of more layering and more indirection. We already have a lot of layering
and indirection when you consider what lives on the other side of the WebKit
API (in the Chromium repository).
One small thing I have wanted to see done is to move all such classes to a
special subdirectory of WebKit/chromium/src to make it clearer that they are
in this special category.
I've noticed that other ports that have their ResourceHandle implementation
in WebCore/platform resort to using WebKit level classes and interfaces
directly to achieve a similar effect. Doing so has similar
abstraction-breaking issues.
With the advent of WebKit2, there was a discussion about this topic as well.
The desire for WebKit2 to support WebCore being built as a separate DSO was
one of the primary reasons given for adding the extra layer of indirection
between WebCore and WebKit for platform level things. (It has been a
non-goal of the Chromium port to build WebCore as a separate DSO.)
There are a lot more interfaces that would be needed besides just
ResourceHandle{Client}. At last count it was fairly substantial. It would
be good to take stock of the entire set before considering a change.
-Darin
On Fri, Sep 10, 2010 at 5:41 PM, Adam Barth aba...@webkit.org wrote:
In investigating the loader, I noticed that Chromium's
ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a
WebCore/platform abstract. Most of the other implementations of
ResourceHandle are in
WebCore/platform/mumble/ResourceHandleMumble.cpp.
Is there a reason why Chromium uses a different design? Normally, we
need a use a virtual function to jump from WebCore to WebKit/chromium.
It looks like we're avoiding that in this case, at the cost of
blurring the layer boundaries.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why is ResourceHandle.cpp in WebKit/chromium/src
That makes a certain amount of sense. It seems like we have three
ways for WebCore to talk to Webkit/foo:
1) Client interfaces
2) PlatformBridge
3) Header-in-WebCore, implementation-in-WebKit/foo
Is there some systematic way of determining which way we should use in
a given circumstance? If we like pattern (3), maybe we should replace
PlatformBridge with (3)? I think there was some talk earlier of
WebKit2 using something called a strategy, which seemed a bit like
(2), but maybe more modular.
To be clear, this came up in my trying to wrap my mine around the
loader. I'm not sure there's anything wrong with (3), it just took me
a while to find Chromium's implementation of ResourceHandle because it
wasn't where I expected it to be.
Adam
On Fri, Sep 10, 2010 at 11:24 PM, Darin Fisher da...@chromium.org wrote:
We use this pattern a lot. You can see that ResourceHandle is implemented
in terms of WebKit API (WebURLLoader).
The alternative is to introduce extra interfaces between WebCore and WebKit.
That has the benefit of isolating WebCore as you say, but it adds the cost
of more layering and more indirection. We already have a lot of layering
and indirection when you consider what lives on the other side of the WebKit
API (in the Chromium repository).
One small thing I have wanted to see done is to move all such classes to a
special subdirectory of WebKit/chromium/src to make it clearer that they are
in this special category.
I've noticed that other ports that have their ResourceHandle implementation
in WebCore/platform resort to using WebKit level classes and interfaces
directly to achieve a similar effect. Doing so has similar
abstraction-breaking issues.
With the advent of WebKit2, there was a discussion about this topic as well.
The desire for WebKit2 to support WebCore being built as a separate DSO was
one of the primary reasons given for adding the extra layer of indirection
between WebCore and WebKit for platform level things. (It has been a
non-goal of the Chromium port to build WebCore as a separate DSO.)
There are a lot more interfaces that would be needed besides just
ResourceHandle{Client}. At last count it was fairly substantial. It would
be good to take stock of the entire set before considering a change.
-Darin
On Fri, Sep 10, 2010 at 5:41 PM, Adam Barth aba...@webkit.org wrote:
In investigating the loader, I noticed that Chromium's
ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a
WebCore/platform abstract. Most of the other implementations of
ResourceHandle are in
WebCore/platform/mumble/ResourceHandleMumble.cpp.
Is there a reason why Chromium uses a different design? Normally, we
need a use a virtual function to jump from WebCore to WebKit/chromium.
It looks like we're avoiding that in this case, at the cost of
blurring the layer boundaries.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Use of Frame by ResourceHandle
I don't mean to spam this list with design questions, but I'm trying to wrap my mind around how the loader is put together today and how we'd like it to be put together in the future. There's a FIXME in ResourceHandle that says that ResourceHandle shouldn't depend on Frame. (For those who aren't familiar with the loader, ResourceHandle is the primary platform abstraction WebCore uses to communicate with the network.) This makes sense to me for two reasons: 1) ResourceHandle is in WebCore/platform/network and therefore isn't allowed to depend on parts of WebCore outside the platform directory. 2) There are a number of types of network requests that are not associated with frames (e.g., XMLHttpRequests from WebWorkers, PingLoader, etc). 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.) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
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. 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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
It seems the dependency on Frame is now gone (as of last night I guess?) with the advent of the NetworkingContext. -Sam On Sat, Sep 11, 2010 at 3:42 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 11, 2010, at 2:57 AM, Adam Barth wrote: I don't mean to spam this list with design questions, but I'm trying to wrap my mind around how the loader is put together today and how we'd like it to be put together in the future. There's a FIXME in ResourceHandle that says that ResourceHandle shouldn't depend on Frame. (For those who aren't familiar with the loader, ResourceHandle is the primary platform abstraction WebCore uses to communicate with the network.) This makes sense to me for two reasons: 1) ResourceHandle is in WebCore/platform/network and therefore isn't allowed to depend on parts of WebCore outside the platform directory. 2) There are a number of types of network requests that are not associated with frames (e.g., XMLHttpRequests from WebWorkers, PingLoader, etc). 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 think this is the right way to go. I don't clearly understand the reasons this dependency was added, but I hope we can find an alternate design to meet those needs. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
Excellent. :) Adam On Sat, Sep 11, 2010 at 4:21 PM, Sam Weinig sam.wei...@gmail.com wrote: It seems the dependency on Frame is now gone (as of last night I guess?) with the advent of the NetworkingContext. -Sam On Sat, Sep 11, 2010 at 3:42 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 11, 2010, at 2:57 AM, Adam Barth wrote: I don't mean to spam this list with design questions, but I'm trying to wrap my mind around how the loader is put together today and how we'd like it to be put together in the future. There's a FIXME in ResourceHandle that says that ResourceHandle shouldn't depend on Frame. (For those who aren't familiar with the loader, ResourceHandle is the primary platform abstraction WebCore uses to communicate with the network.) This makes sense to me for two reasons: 1) ResourceHandle is in WebCore/platform/network and therefore isn't allowed to depend on parts of WebCore outside the platform directory. 2) There are a number of types of network requests that are not associated with frames (e.g., XMLHttpRequests from WebWorkers, PingLoader, etc). 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 think this is the right way to go. I don't clearly understand the reasons this dependency was added, but I hope we can find an alternate design to meet those needs. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why is ResourceHandle.cpp in WebKit/chromium/src
On Sep 11, 2010, at 2:49 AM, Adam Barth wrote: That makes a certain amount of sense. It seems like we have three ways for WebCore to talk to Webkit/foo: 1) Client interfaces 2) PlatformBridge 3) Header-in-WebCore, implementation-in-WebKit/foo Is there some systematic way of determining which way we should use in a given circumstance? If we like pattern (3), maybe we should replace PlatformBridge with (3)? I think there was some talk earlier of WebKit2 using something called a strategy, which seemed a bit like (2), but maybe more modular. To be clear, this came up in my trying to wrap my mine around the loader. I'm not sure there's anything wrong with (3), it just took me a while to find Chromium's implementation of ResourceHandle because it wasn't where I expected it to be. We have a start on the strategy pattern, you can see it in: WebCore/platform/PlatformStrategies.h WebProcess/WebCoreSupport/WebPlatformStrategies.cpp WebKit/mac/WebCoreSupport/WebPlatformStrategies.mm WebKit/win/WebCoreSupport/WebPlatformStrategies.cpp The strategy pattern is intended for cases where the implementation of something in WebCore is to be virtualized up to the WebKit layer, including the possibility of switching at runtime, but it's expected to be a global switch for that particular instance of WebCore, not per-object. Client interfaces, on the other hand, are intended as callback interfaces for code that is logically on top of WebCore, to provide notifications and the opportunity for policy-type decisions. I think the modular Strategy pattern is better than the monolithic Bridge pattern. Way back in the day we used to have a single WebCoreBridge as the interface between WebCore and WebKit. We moved away from that design because it was messy and the bridge had a tendency to become a god object over time. Our bridge was also a two-way bridge (various methods implemented on each side) which I think is not the case with the chromium bridge. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
On Sep 11, 2010, at 4:21 PM, Sam Weinig wrote: It seems the dependency on Frame is now gone (as of last night I guess?) with the advent of the NetworkingContext. Neat. I was going to suggest using factory objects to create ResourceHandles (then they can stuff in whatever info they need, or add an external association or whatever), but I am not sure of the right scope for the factory. One per frame clearly, but Worker and SharedWorker would need separate handling. Perhaps they could piggyback off the factory of the initially creating frame. Regards, Maciej -Sam On Sat, Sep 11, 2010 at 3:42 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 11, 2010, at 2:57 AM, Adam Barth wrote: I don't mean to spam this list with design questions, but I'm trying to wrap my mind around how the loader is put together today and how we'd like it to be put together in the future. There's a FIXME in ResourceHandle that says that ResourceHandle shouldn't depend on Frame. (For those who aren't familiar with the loader, ResourceHandle is the primary platform abstraction WebCore uses to communicate with the network.) This makes sense to me for two reasons: 1) ResourceHandle is in WebCore/platform/network and therefore isn't allowed to depend on parts of WebCore outside the platform directory. 2) There are a number of types of network requests that are not associated with frames (e.g., XMLHttpRequests from WebWorkers, PingLoader, etc). 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 think this is the right way to go. I don't clearly understand the reasons this dependency was added, but I hope we can find an alternate design to meet those needs. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why is ResourceHandle.cpp in WebKit/chromium/src
On Sat, Sep 11, 2010 at 2:49 AM, Adam Barth aba...@webkit.org wrote:
That makes a certain amount of sense. It seems like we have three
ways for WebCore to talk to Webkit/foo:
1) Client interfaces
2) PlatformBridge
3) Header-in-WebCore, implementation-in-WebKit/foo
Is there some systematic way of determining which way we should use in
a given circumstance?
Good question.
Historically, we started off using #2 exclusively, except for
ResourceHandle. There was probably not a good reason for ResourceHandle
being different at the time.
PlatformBridge (previously named ChromiumBridge) was invented to help solve
the very problem that led you here. I wanted us to have all WebCore symbols
(except for the ChromiumBridge symbols) defined in WebCore. This way if you
found something implemented in terms of ChromiumBridge functions, you would
know to follow the trail to the WebKit layer's ChromiumBridge
implementation. ChromiumBridge was to be the enumeration of the WebCore
symbols left undefined by WebCore.
One issue with ChromiumBridge is that people are forced to replicate
functions on ChromiumBridge that correspond to other WebCore/platform class
methods (e.g., see PlatformScreenChromium.cpp). This is unfortunate and
tedious for people. The ResourceHandle model was less work to implement and
less work to maintain, so that model became popular. See
WebKit/chromium/src/GraphicsContext3D.cpp for example!
If we like pattern (3), maybe we should replace
PlatformBridge with (3)?
Yes, perhaps we should do that. In concert with that, it would be good to
create a subdirectory in WebKit/chromium/src for these WebCore class
implementations.
I'm concerned that the PlatformStrategies approach adds too much maintenance
overhead given the number of interfaces we'd need to add to it.
I like low cost and easy to maintain solutions that are intuitive for
developers. I think solution #3 as currently implemented suffers from not
being intuitive. If we can fix that, then we should be good.
-Darin
I think there was some talk earlier of
WebKit2 using something called a strategy, which seemed a bit like
(2), but maybe more modular.
To be clear, this came up in my trying to wrap my mine around the
loader. I'm not sure there's anything wrong with (3), it just took me
a while to find Chromium's implementation of ResourceHandle because it
wasn't where I expected it to be.
Adam
On Fri, Sep 10, 2010 at 11:24 PM, Darin Fisher da...@chromium.org wrote:
We use this pattern a lot. You can see that ResourceHandle is
implemented
in terms of WebKit API (WebURLLoader).
The alternative is to introduce extra interfaces between WebCore and
WebKit.
That has the benefit of isolating WebCore as you say, but it adds the
cost
of more layering and more indirection. We already have a lot of layering
and indirection when you consider what lives on the other side of the
WebKit
API (in the Chromium repository).
One small thing I have wanted to see done is to move all such classes to
a
special subdirectory of WebKit/chromium/src to make it clearer that they
are
in this special category.
I've noticed that other ports that have their ResourceHandle
implementation
in WebCore/platform resort to using WebKit level classes and interfaces
directly to achieve a similar effect. Doing so has similar
abstraction-breaking issues.
With the advent of WebKit2, there was a discussion about this topic as
well.
The desire for WebKit2 to support WebCore being built as a separate DSO
was
one of the primary reasons given for adding the extra layer of
indirection
between WebCore and WebKit for platform level things. (It has been a
non-goal of the Chromium port to build WebCore as a separate DSO.)
There are a lot more interfaces that would be needed besides just
ResourceHandle{Client}. At last count it was fairly substantial. It
would
be good to take stock of the entire set before considering a change.
-Darin
On Fri, Sep 10, 2010 at 5:41 PM, Adam Barth aba...@webkit.org wrote:
In investigating the loader, I noticed that Chromium's
ResourceHandle.cpp is in WebKit/chromium/src. ResourceHandle is a
WebCore/platform abstract. Most of the other implementations of
ResourceHandle are in
WebCore/platform/mumble/ResourceHandleMumble.cpp.
Is there a reason why Chromium uses a different design? Normally, we
need a use a virtual function to jump from WebCore to WebKit/chromium.
It looks like we're avoiding that in this case, at the cost of
blurring the layer boundaries.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
On Sat, Sep 11, 2010 at 9:17 AM, Adam Barth aba...@webkit.org wrote: On Sat, Sep 11, 2010 at 8:15 AM, Holger Freyther ze...@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 don't understand. WebWorkers use ThreadableLoader, which routes the network request back to the main thread where there is an associated Frame. (SharedWorkers have a dummy frame associated with them.) By the way, the Chromium port once used the Frame pointer that was passed to ResourceHandle. This was back before we opensourced. At that time, loadResourceSynchronously did not take a Frame pointer. When, I suggested adding that Frame pointer (see https://bugs.webkit.org/show_bug.cgi?id=14106), I was corrected (by Maciej on #webkit IIRC) on the grounds that it propagated a layering violation. His suggested workaround was to leverage FrameLoaderClient::dispatchWillSendRequest, and that worked great. It allowed us to tag the ResourceRequest with information that was Frame specific before the ResourceHandle was created. I wonder why NetworkingContext is necessary given FrameLoaderClient::dispatchWillSendRequest. (I also wonder why https://bugs.webkit.org/show_bug.cgi?id=16588 wasn't resolved WONTFIX like bug 14106.) -Darin 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
On Sat, Sep 11, 2010 at 10:02 PM, Darin Fisher da...@chromium.org wrote: On Sat, Sep 11, 2010 at 9:17 AM, Adam Barth aba...@webkit.org wrote: On Sat, Sep 11, 2010 at 8:15 AM, Holger Freyther ze...@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 don't understand. WebWorkers use ThreadableLoader, which routes the network request back to the main thread where there is an associated Frame. (SharedWorkers have a dummy frame associated with them.) See. The dummy frame sounds unfortunate. In general, there are also situations on the main thread where we'd like to perform a load without a Frame. I'd have to look at the details, but there are long-standing bugs about applying XSLT to Frame-less documents. Also, the PingLoader doesn't have a Frame available (it's job is to make image requests that outlive the Frame). By the way, the Chromium port once used the Frame pointer that was passed to ResourceHandle. This was back before we opensourced. At that time, loadResourceSynchronously did not take a Frame pointer. When, I suggested adding that Frame pointer (see https://bugs.webkit.org/show_bug.cgi?id=14106), I was corrected (by Maciej on #webkit IIRC) on the grounds that it propagated a layering violation. His suggested workaround was to leverage FrameLoaderClient::dispatchWillSendRequest, and that worked great. It allowed us to tag the ResourceRequest with information that was Frame specific before the ResourceHandle was created. I wonder why NetworkingContext is necessary given FrameLoaderClient::dispatchWillSendRequest. (I also wonder why https://bugs.webkit.org/show_bug.cgi?id=16588 wasn't resolved WONTFIX like bug 14106.) In general, there is no necessary connection between network requests made by WebCore and Frames. Techniques that aim to associate a frame with every network request won't work in some cases because such a Frame might not exist. I need to study NetworkContext more closely, but it seems like it would be useful for remembering which network backend is supposed to service a given ResourceHandle. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
On Sat, Sep 11, 2010 at 10:42 PM, Adam Barth aba...@webkit.org wrote: On Sat, Sep 11, 2010 at 10:02 PM, Darin Fisher da...@chromium.org wrote: On Sat, Sep 11, 2010 at 9:17 AM, Adam Barth aba...@webkit.org wrote: On Sat, Sep 11, 2010 at 8:15 AM, Holger Freyther ze...@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 don't understand. WebWorkers use ThreadableLoader, which routes the network request back to the main thread where there is an associated Frame. (SharedWorkers have a dummy frame associated with them.) See. The dummy frame sounds unfortunate. It solved/avoided a load of problems/complexity. What are your concerns? In general, there are also situations on the main thread where we'd like to perform a load without a Frame. I'd have to look at the details, but there are long-standing bugs about applying XSLT to Frame-less documents. Also, the PingLoader doesn't have a Frame available (it's job is to make image requests that outlive the Frame). PingLoader has an associated Frame when it kicks off the load. That is the critical time when Frame association is usually needed. For example, you cannot load any network requests in Chromium unless you know what Page (you need to know the routing ID of the tab) is requesting the resource. I assume PingLoader still generates the FrameLoaderClient::dispatchWillSendRequest notification, right? How do you get a frame-less document? Via XMLHttpRequest.responseXML? Perhaps it could use the Frame of the script execution context? (Which script execution context is a good question.) By the way, the Chromium port once used the Frame pointer that was passed to ResourceHandle. This was back before we opensourced. At that time, loadResourceSynchronously did not take a Frame pointer. When, I suggested adding that Frame pointer (see https://bugs.webkit.org/show_bug.cgi?id=14106), I was corrected (by Maciej on #webkit IIRC) on the grounds that it propagated a layering violation. His suggested workaround was to leverage FrameLoaderClient::dispatchWillSendRequest, and that worked great. It allowed us to tag the ResourceRequest with information that was Frame specific before the ResourceHandle was created. I wonder why NetworkingContext is necessary given FrameLoaderClient::dispatchWillSendRequest. (I also wonder why https://bugs.webkit.org/show_bug.cgi?id=16588 wasn't resolved WONTFIX like bug 14106.) In general, there is no necessary connection between network requests made by WebCore and Frames. Techniques that aim to associate a frame with every network request won't work in some cases because such a Frame might not exist. There always has been such an association. I would like to understand the concerns better. I guess it means that I need to understand the frame-less document issue and why you think having a dummy frame associated with shared workers is a problem. -Darin I need to study NetworkContext more closely, but it seems like it would be useful for remembering which network backend is supposed to service a given ResourceHandle. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
