On Tuesday, September 5, 2017 at 10:57:58 AM UTC-7, Jim Blandy wrote: > As an offer of help, from a group whose charter covers this work, that's > very welcome. I felt that I was being shepherded into something on behalf > of others for whom I cannot speak, which was uncomfortable! > > For my own sake, I am disinclined to participate in a standardization > effort outside of the usual institutions. I think we could benefit from the > experience of people who have produced web standards before. I'm not > well-connected enough yet to anticipate what folks will say, but I'll > suggest the Browser Testing Tools WG when the opportunity comes up. > > > On Tue, Sep 5, 2017 at 5:32 AM, James Graham <ja...@hoppipolla.co.uk> wrote: > > > On 04/09/17 23:34, Jim Blandy wrote: > > > >> On Mon, Sep 4, 2017 at 7:36 AM, David Burns <dbu...@mozilla.com> wrote: > >> > >>> I don't think anyone would disagree with the reasons for doing this. I, > >>> > >> like James who brought it up earlier, am concerned that we from the emails > >> appear to think that implementing the wire protocol would be sufficient to > >> making sure we have the same semantics. > >> > >> LOL, give us a little credit, okay? The authors of the email do not think > >> that. We want to have a properly written specification and conformance > >> tests. I think you're reading "we have no interest in established > >> standardization processes" when what we wrote was "the process is in very > >> early stages". > >> > >> Do you think the Browser Testing Tools WG is the right body to work on a > >> JS > >> debugging and console protocol, used by interactive developer tools? That > >> seems like a surprising choice to me. > >> > > > > It is certainly not the only possible venue, but if you want to do the > > work at the W3C then it's probably the easiest way to get things going from > > a Process point of view, since this kind of protocol would be in the > > general remit of the group, and the rechartering could add it specifically. > > Certainly the people currently in the group aren't the right ones to do the > > work, but adding new participants to work specifically on this would be > > trivial. > > > > Also - at least as far as I know - this is not where the current > >> participants in the discussion (Kenneth Auchenberg or Christian Bromann, > >> to > >> name two) have been working. Is having a previously uninvolved standards > >> committee take up an area in which current activity is occurring elsewhere > >> considered friendly and cooperative behavior? It seems unfriendly to me. I > >> would like to avoid upsetting the people I'm hoping to work closely with. > >> > > > > I think you have misinterpreted the intent here. I don't think anyone is > > interested in doing a hostile takeover of existing work. But there is > > concern that the work actually happens. Pointing at remotedebug.org, > > which has been around since 2013 without producing any specification > > materials, isn't helping assuage my concerns, and I guess others are having > > a similar reaction. It is of course entirely possible that there's work > > going on that we can't see. But my interpretation of David's email is that > > he is trying to offer you options, not force you down a certain path. The > > W3C is not always the right venue to work in, but it is sometimes sought > > out by organisations who would likely participate in this work because of > > its relatively strong IPR policy. > > > > I should stress that irrespective of venue I would expect this > > standardisation effort to take years; people always underestimate the work > > and time required for standards work. It will certainly require us to > > commit resources to make it happen. > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > >
Hi everyone, Kenneth, the original initiator of RemoteDebug here. I just want to provide an overview of the state of the RemoteDebug initiative and how I see CDP fit into the broader tooling ecosystem. Status of RemoteDebug Now several years after I initiated RemoteDebug a lot has happened in the tooling ecosystem, as we today have several 3rd party tools build on and around CDP by the big players (Debugger.html by Mozilla, Lighthouse+ Puppeteer by Google, and Sonar + VS Code debuggers by Microsoft), which has reinforced that CDP is the de-facto DevTools "standard" protocol. At the last Chrome DevSummit (2016) we had a meeting where Firefox DevTools, Edge DevTools and Chrome DevTools where present to discuss the latest RemoteDebug proposal, the RemoteDebug DevTools Core Specification [1], which could serve as an implementation starting point for new vendors who want to embrace CDP compatibility but focus on the stable parts of the API. At the meeting it was agreed that Google would focus on stabilizing most of the CDP API in its CDP 1.2 version (which today is the most recent version) while continue to experiment with new APIs marked as experimental in the protocol. When looking at the RemoteDebug DevTools Core and the stable APIs within CDP it's clear that most of the API surface has been stable sine the early WebKit days, which is good news for existing tools and for new implementors. The API differences can be browsed through the RemoteDebug Compatibility Tables [10] >From a process perspective the idea of the RemoteDebug DevTools Core >Specification has been to embrace the same process as the ServiceWorker >specification which was build around GitHub, and later promoted to a W3C spec >once a foundation has been agreed upon by multiple vendors. I'm open to >transition RemoteDebug and all related work to the W3C Browser Testing Tools >WG, if this could help ensure commitment from Mozilla and others. Until now most of the conversations for RemoteDebug/CDP has been ad-hoc conversations between Chrome, Firefox, Edge and VS Code as the number of persons involved in the protocol discussions has been very limited. Overview of CDP in the tooling system As I started out by saying then CDP has emerged as the defacto "DevTools" standard protocol as most of the major players now have tools and project based on CDP. I would look at CDP in a similar way to WebDriver as something that can live in parallel to what-ever Firefox currently exposes today. >From Microsoft (my employer) we have been pushing CDP as our preferred >protocol for our VS Code debuggers in vscode-chrome-debug-core [2], which is >now powering 6x VS Code debuggers and the Node debugger in Visual Studio. >Microsoft backed Project Sonar adapted by the JS Foundation is also based on >CDP [4] Additionally it was just announced at the Edge Summit 2017 that >Microsoft Edge is gonna introduce the Edge DevTools protocol based on JSON RPC >over WebSockets with the aim to be highly compatible with CDP. This means that >future version of Edge DevTools most likely will be solely powered by a CDP >dialect. [3]. Microsoft has also contributed to remotedebug-ios-webkit-adapter which enables iOS WebKit to be debugged from VS Code and Chrome DevTools, by working as an API adaptor mapping the WebKit API to CDP. [8] Google contributed an CDP implementation for Node.js, which has now become the default debugging protocol for Node under the name "Inspector protocol" which has enables tools like Chrome DevTools to debug Node out of the box. [5]. We have also seen Google building tools like Lighthouse [6] and Puppeteer [7] which also are based on CDP, and used in Chrome Headless where CDP is the preferred API. As already mentioned in this thread, when we have also seen Mozilla building debugger.html which is powered by CDP [11]. On top of these larger projects the open-source community has also been building a broad range of tools and CDP clients [9] It can be discussed whether CDP is the most technical elegant solution, but it can't be ignored that it's a well proven protocol (JSON RPC over WebSockets) which has been used since Webkit introduced remote debugging, and today we all major vendors either exposing CDP or consuming CDP in some form (Apple, Microsoft, Mozilla, Google, Opera, Samsung) within their web runtime or tooling. CDP isn't perfect, and is know to have shortcomings for feature/API detection, but these are things that easily can be resolved by introducing this to the API surface. >From my perspective we have now reached a critical point in CDP's adaption as >we have a rich tooling ecosystem using the APis while most of the API surface >has been stabilized in CDP 1.2, which speaks in favor of moving forward with a >formel spec and for other vendors to begin their implementations. [1] https://github.com/RemoteDebug/devtools-core-spec [2] https://github.com/Microsoft/vscode-chrome-debug-core [3] https://mobile.twitter.com/auchenberg/status/908721908782428160 [4] https://sonarwhal.com/ [5] https://github.com/nodejs/node/pull/6792 [6] https://github.com/GoogleChrome/lighthouse [7] https://github.com/GoogleChrome/puppeteer [8] https://github.com/RemoteDebug/remotedebug-ios-webkit-adapter [9] https://github.com/ChromeDevTools/awesome-chrome-devtools [10] http://compatibility.remotedebug.org/ [11] https://github.com/devtools-html/debugger.html _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
