Bug 43732 – Web Inspector: Remote debugging meta-bug

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Pavel Feldman]

Here is how I see it:
- Ilya completes his work on generating transport for new InspectorBackend <-> InspectorFrontend interaction
- There are two types of messages flying between backend and frontend: push and query. inspector.idl defines present versions of these messages, push methods are marked with [notify].
- We change the JSON message format a bit, leaving existing semantics of messages in place. Following draft should give a good idea on the message format: https://docs.google.com/document/edit?id=1d_N-OIb3UztuC-_g0piXsIIdp89HnMcDk-uSQ8uamW4&hl=en&authkey=CIf48O4J
- Ilya generates nice API on the JavaScript side that issues messages described above and hides the 'call id / seq number' logic from the client:

// Issues a 'set' 'child-nodes' command.
InspectorBackend.dom.setChildNodes = function(arg1, callbackFunction) {
   ...
}

- Every query message is going to have an ack and as a result, query messages are going to be of the following form (from client's code perspective):

InspectorBackend.dom.setChildNodes(1, function(results) { ... });

- Approach described above might be sufficient for some domains (cookies, appcache). But there are more complex domains such as 'dom' that maintain heavy state. For these, I'd suggest implementing an 'SDK' that would maintain model consistency and encapsulate backend interaction. In dom case, DOMAgent is pretty much covering it, but needs to brushed up a bit. It no longer needs to mimic DOM interface, enulate DOMWindow and such.
- Over time, we could deliver these SDKs to the remote debugging clients and hence allow alternate front-ends. As a result, we will need to maintain JavaScript SDK conformance instead of the protocol conformance. Just as we do with Eclipse Debugger for Chrome.

[Joseph Pecoraro]

> - We change the JSON message format a bit, leaving existing semantics of messages
> in place. Following draft should give a good idea on the message format:
> https://docs.google.com/document/edit?id=1d_N-OIb3UztuC-_g0piXsIIdp89HnMcDk-uSQ8uamW4&hl=en&authkey=CIf48O4J

Very useful, thanks for putting this together.


> - Approach described above might be sufficient for some domains (cookies, appcache). But there are more
> complex domains such as 'dom' that maintain heavy state. For these, I'd suggest implementing an 'SDK' that
> would maintain model consistency and encapsulate backend interaction. In dom case, DOMAgent is pretty
> much covering it, but needs to brushed up a bit. It no longer needs to mimic DOM interface, enulate DOMWindow
> and such.
>
> - Over time, we could deliver these SDKs to the remote debugging clients and hence allow alternate front-ends.
> As a result, we will need to maintain JavaScript SDK conformance instead of the protocol conformance. Just as
> we do with Eclipse Debugger for Chrome.

I think that is a good idea. Its much easier to maintain a few method names and their parameters, then maintain
an "old" and "new" protocol if it ever changes.

[Steven Roussey]

Reference interface for such an SDK (work in progress for use in Firebug and Eclipse):

http://code.google.com/p/fbug/source/browse/branches/firebug1.7#firebug1.7/content/firebug/interface

[Brian Burg]

Closing as invalid, as this bug pertains to the old inspector UI and/or its tests.
Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.