Hi all, (this is my fake "Network Service" mailing list for now!)

Now that we've got some DEPS entries added to c/b/loader/DEPS, I thought I'd try
looking at actually decoupling something. This is a bit long, partly I'm hoping
to have a discussion on how we should approach things in general.

I picked content/browser/devtools/devtools_netlog_observer.h arbitrarily as it
was used in a couple places, but not used everywhere. It's got direct calls from
a couple files:

https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/sync_resource_handler.cc&q=DevToolsNetLogObserver&sq=package:chromium&type=cs&l=54
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/async_resource_handler.cc&l=304

DevToolsNetLogObserver::PopulateResponseInfo() sets a field in
ResourceResponseInfo (which will live itself in the network service eventually
[1]).

My naive understanding of this class is that it's responsible for mirroring
entries that net/ adds to NetLog back into ResourceResponseInfo in the
devtools_info field (for content/child devtools code to inspect later). This
data at the moment includes the status code, the request/response headers and
the request/response text.

Adding the "obvious" delegate interface would be one way. I think it'd have to
synchronously call from network->content to provide the netlog data, and then
synchronously again have content attach the data to the request. That seems
pretty heavy.

One alternative would be to move all of it into network and always attach that
information. I assume that's either expensive or undesirable for other reasons
(leaking something to renderers that shouldn't have it?). So maybe the delegate
should just be something like "bool ShouldIncludeExtraInformationForDevTools()"
(with a better name) but the actual information that's recorded is determined by
the network. So that would mean moving
content/public/common/resource_devtools_info.h and
content/browser/devtools/devtools_netlog_observer.(cc|h) to network (probably
renaming them), and then we have to have a translation of that data from the
network side to the content side when the renderer is accessing it. (This is
true of all of ResourceReponseInfo I guess though.)

Anyone get all that? These refactorings seem like they'll be a lot more work to
figure out and explain than they will be to actually do! Any thoughts?

(I may not be making a lot of sense here as I'm not knowledgable about this code
at all... I might just need to stare at it and try some things to understand
better tactics.)

[1] https://docs.google.com/spreadsheets/d/1ot0WOgC2TrMY5VADo2ijmx98Z792FojUKJncG5u3QRo/edit#gid=0