The Roadmap.

The long-term goal is to get all major browser vendors to implement and use the "RemoteDebug", but we know this is going to take some time, especially to get everyone on board.

1. Protocol and API baseline

The first thing is to get a baseline for the protocol and API. The current proposal is to use the existing Chrome Remote debugging protocol as our starting point to define what we would call the RemoteDebug protocol and RemoteDebug API.

The arguments for choosing the Chrome Remote debugging protocol is:

2. Gain overview of functionality in existing protocols and API's (Current phase)

This phase requires a lot of research, where functionaliy in existing protocols and API's needs to get mapped out. This work has been been started with our compatibility section.

3. Protocol and API specifications

The next step is a two-fold specification strategy, as the API also could be used within the browser as an WebIDL. First is to kick-off the specification work of the remote debugging protocol itself and the API used over the protocol.

4. Provide protcol adaptors for browsers

Once the first revisions of the protocol and API has been stablized, the work on providing protocol adaptors for the existing remote debugging protocols should be started. A prototype of such a bridge has already been demonstrated by Kenneth Auchenberg, with his remotedebug-firefox-bridge.

Currently the thinking is that the taget browsers should be priorized after market share.

5. Make browsers use RemoteDebug as their default interface

A standards and political effort for browsers to support the RemoteDebug protocol and RemoteDebug API as their primary, should be started.

6. Migrate existing tools and build new ones!

When we get here - a new world of web tooling will be open.