Updated info on Inspector Protocol (CDP)

[joshgav]

This adds

• an initial list of informational resources about the Inspector Protocol
• tables to track support in tools and runtimes for protocol domains.

Is this the right format to track compat?
Can tool and runtime owners update their rows?

/cc @nodejs/diagnostics @ofrobots @auchenberg @jasonLaster @develar

[auchenberg]

I've started on the RemoteDebug Compatibility tables that compares protocol.json's from Chrome, Safari, Edge and Node.

It's early days, but it should provide a better overview of what parts of the API that are stable and implemented across runtimes: http://compatiblity.remotedebug.org/

Repo: https://github.com/RemoteDebug/remotedebug-compatibility-tables

[pavelfeldman]

@joshgav: Should we rather track the clients of the protocol for Node along with their capabilities? I am not sure listing the backend methods various backends expose makes much sense for Node - that should be clients' business to declare / track the backends they support.

[develar]

IntelliJ IDEs support ("use") Debugger, Console, Runtime, Worker (doesn't make any sense for node, right?).

[joshgav]

@pavelfeldman

I am not sure listing the backend methods various backends expose makes much sense for Node

Is this because you believe Node should provide a single set of domains regardless of backend VM? I was thinking such a standard set would only be a subset of the capabilities of V8 or other VMs, and the full set could be documented here.

In the short term V8 is the only VM and it's reasonable to focus mostly on it. But I hope our work here will contribute to JavaScript diagnostics in the long term, so wanted to try to keep other runtimes in mind.

Going back to edit this now. Will add @auchenberg's links too. Thanks!

[pavelfeldman]

But I hope our work here will contribute to JavaScript diagnostics in the long term, so wanted to try to keep other runtimes in mind.

Not sure I follow the long term goal here. What exactly are you trying to achieve?

[joshgav]

@pavelfeldman trying to keep in mind that our effort here is the likely foundation for diagnostic interfaces for non-browser JS in the future, including future Node and Node alternatives.

But agree that Node+V8 are primary.

[joshgav]

Closing.

Ongoing protocol discussion can continue in @auchenberg's links above and perhaps at https://github.com/ChromeDevTools/debugger-protocol-viewer.

Debugging getting started guide for web site proposed here: nodejs/nodejs.org#1131