Currently core/inspector depends on core/xml/XMLHttpRequest*.
Is there any concern from inspector developers to remove the dependency?
On Mon, Jul 14, 2014 at 9:40 AM, Takeshi Yoshino <tyos...@chromium.org> wrote:There are a couple of outstanding issues on exactly what kind of
> Can we assume that the Fetch API spec is already maintained considering use
> in non-SW world well enough so that it's fine to be implemented and exposed?
headers we want to include. And whether caching should be automatic or
not, see the service workers repository. We can only get it more
stable by implementing and figuring out if the setup works I think. I
would prefer if we not ship for a couple of months to make sure we all
agree on the details of the API and what happens at the networking
layer, but getting something in the hands of developers would be
great.
You question seems to boil down to whether we should have dependencies between modules. We recently introduced our first inter-module dependency (that I'm aware of) so that push_messaging could depend on serviceworker.I'm a little scared about having cross-module dependencies because one of the goals of modules is to make the system more loosely coupled. Dependencies between modules can lead to tighter coupling. IMHO, we should see how the push_messaging/serviceworker dependency works out before adding more cross-module dependencies.From the dependencies you've listed, it sounds like |streams| should be in core because it's depended upon by both modules/fetch and modules/serviceworker.
w.r.t. inspector depending on XMLHttpRequest, we should likely generalize a lot of that code to handle other sorts of script-based network APIs (e.g., EventSource). However, until we do that, you'll need to keep XMLHttpRequest in core other you'll introduce a core -> modules dependency that will prevent blink_core.dll from linking (once we create it).
On Tue, Jul 15, 2014 at 1:02 AM, Adam Barth <aba...@chromium.org> wrote:
You question seems to boil down to whether we should have dependencies between modules. We recently introduced our first inter-module dependency (that I'm aware of) so that push_messaging could depend on serviceworker.I'm a little scared about having cross-module dependencies because one of the goals of modules is to make the system more loosely coupled. Dependencies between modules can lead to tighter coupling. IMHO, we should see how the push_messaging/serviceworker dependency works out before adding more cross-module dependencies.From the dependencies you've listed, it sounds like |streams| should be in core because it's depended upon by both modules/fetch and modules/serviceworker.I see. I think several other web platform features are also going to depend on |streams| in addition to them in the future. So, following the approach you suggested, I agree we should place |streams| in core/.
w.r.t. inspector depending on XMLHttpRequest, we should likely generalize a lot of that code to handle other sorts of script-based network APIs (e.g., EventSource). However, until we do that, you'll need to keep XMLHttpRequest in core other you'll introduce a core -> modules dependency that will prevent blink_core.dll from linking (once we create it).Yutaka is looking at the inspector -> xhr dependency. Yes, it seems we can generalize the hooks that are now defined specifically for XHR.So, initially:- We keep XHR in core/xml- And add |streams| to core/streamsand later as refactoring is done and see the result of cross-module dependency, we could reorganize them.One non trivial question is whether we really want to decouple fetch API code from modules/serviceworkers. I thought we want to and the right place would be some sub directory in core/ as we don't want to introduce cross-module dependencies (core/fetch is irrelative to the Fetch concept (http://src.chromium.org/viewvc/blink?view=revision&revision=155987), so some different name...). Thoughts?
You question seems to boil down to whether we should have dependencies between modules. We recently introduced our first inter-module dependency (that I'm aware of) so that push_messaging could depend on serviceworker.I'm a little scared about having cross-module dependencies because one of the goals of modules is to make the system more loosely coupled. Dependencies between modules can lead to tighter coupling. IMHO, we should see how the push_messaging/serviceworker dependency works out before adding more cross-module dependencies.From the dependencies you've listed, it sounds like |streams| should be in core because it's depended upon by both modules/fetch and modules/serviceworker.
On Monday, July 14, 2014 12:02:58 PM UTC-4, Adam Barth wrote:You question seems to boil down to whether we should have dependencies between modules. We recently introduced our first inter-module dependency (that I'm aware of) so that push_messaging could depend on serviceworker.I'm a little scared about having cross-module dependencies because one of the goals of modules is to make the system more loosely coupled. Dependencies between modules can lead to tighter coupling. IMHO, we should see how the push_messaging/serviceworker dependency works out before adding more cross-module dependencies.From the dependencies you've listed, it sounds like |streams| should be in core because it's depended upon by both modules/fetch and modules/serviceworker.But than core cannot depend on modules, so isn't it rather a counter argument?
Adam