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.