[Webkit-unassigned] [Bug 25347] Add a FrameLoaderClient callback for the ResourceRetrievedByXMLHttpRequest.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25347





------- Comment #6 from pfeldman at chromium.org  2009-04-23 22:46 PDT -------
(In reply to comment #5)
> (In reply to comment #4)
> > It will take me some time to split InspectorController and I don't want
> > Chromium guys to be blocked by that
> 
> Blerg, not what I meant to paste.  I meant to ask is if this is to help the
> unforking of chromium or to some other experimental work?
> 

Here is a broader context: I am currently working on Elements and Resources
tabs to allow their async operation. Yury is working on debugger, Mikhail is
working on Profiler. The 'work' that they are doing is about making Chromium's
internals ready to provide information required and patch/refactor WebInspector
to allow async operation in respective areas.

Before I dive into splitting InspectorController, I would like to make sure
that they are not blocked with what I am doing. As I explained above, our
experimental agents are outside WebCore (we needed those to make this thing
running out of process and not to clash with Dmitry's effort). But they are
missing some information. In particular, Yury is being blocked with the XmlHttp
data absence and I am trying to fix this. That is why I need it, but I am sure
that having it exposed to loader client is anyway a good thing.

Now about our 'experimental' work: it is entirely open, in Chromium repository,
located in webkit/glue/devtools folder. It is really not much - a thousand
lines of code that mimic InspectorController and establish an RPC-alike
interaction with WebInspector. That is something we are using as a proof of
concept when bringing code into WebKit.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.