[Webkit-unassigned] [Bug 54112] Web Inspector: Add Start/Stop commands for (sub-)frontend lifetime agents.

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Pavel Feldman <pfeldman at chromium.org>  2011-02-17 22:44:39 PST ---
Ok, now that IDL is split we can go on with this one.

Originally, I was pushing for agent lifetime being < than frontend lifetime. I.e. agent was created upon request from the front-end and then was destroyed once it was not needed upon stop. Timeline agent existed only between the start and stop calls, debugger agent only existed while debugging was enabled, etc. The idea is nice, but I now think it overcomplicates things for no good reason:

- Now that we want to make sart and stop a part of the domain itself, timeline agent should somehow create itself upon start and wipe itself out form its inspectorAgent container upon stop. To achieve this we either need to make start / stop static and allow agents register themselves in InspectorAgent or invent some other wipe-out mechanism that is going to add nothing but indirection. It sounds kinda complex.
- Originally, we were thinking "agent lifetime spans within frontend, should we need some instrumentation outside these bounds, instrumented data should be stored in some managers / storages that live in inspector agent". However, this is bad for following reasons: a) it provides coupling between InspectorAgent and subagents and b) we were lazy and there are InspectorCSSAgent, InspectorConsoleAgent that live as much as the page c) InspectorDatabase with its in-agent storage looks ugly.
- I really think we should nuke inspector agent -> subagent dependency in order to make addition of agents modular, with no need to modify core InspectorAgent structure.


It all adds up and here is another plan that I would suggest:
[PLAN B]

- Sub-agents (or now first-class-citizen agents)'s lifetime == InspectorController lifetime.
- They all share base class with the following API: setFrontend and clearFrontend.
- They live in a single Vector of pointers, InspectorController only knows their base API above, they are constructed in the InspectorController constructor. Exception is agents that should be called upon WebKit calls such as startUserInitiatedProfiling. They are both referenced in vector (owned) and in raw pointer of a more concrete class in InspectorController.
- InspectorInstrumentation is mapping page to InspectorAgent today. Instead, it will map page to the struct of "active agents". You can think of this struct as of a reduced InspectorAgent (without ownership of agents).
- Agents receive start / stop calls from the front-end and upon these calls, they register themselves in the inspector instrumentation as "active".
- There are inter-agent dependencies (BrowserDebugger -> Debugger, InspectorAgent -> DomAgent). Let agents receive their dependencies in the constructor for now.
- To handle didCommitLoad gently, InspectorInstrumentation will have two methods:
didCommitLoad and didCommitLoadForMainFrame. ResourceAgent will be called in the first, rest of the agents in the second. They all will have didCommitLoadForMainFrame in their APIs.
- Workers are likely to have their own instrumentation interface. They are free to reuse debugger agent and a part of its protocol, they will not expose databases (we can always explore databases from the main thread), they are likely to use their own network instrumentation.

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