Google has indicated a willingness to participate in standardizing the protocol.
If we switch from a devtools protocol used only by us to a tooling protocol used by the rest of the industry, that is strictly an improvement over the status quo, even if our implementation deviates from the others' to some degree: developers whose tooling doesn't run into the points of incompatibility can now include Firefox in their scripting and tests, and the maintainers of tooling that use the CDP can work around incompatibilities. I think it's a mistake to analogize this too closely to content-exposed APIs. Those are under extreme backwards compatibility pressure, of a sort that I think doesn't hold here. Unlike a web user, who simply sees a broken page and can't do anything about it, our audience is more technical, and can do things like upgrade tools when things don't work. On Thu, Aug 31, 2017 at 1:09 PM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 31/08/17 19:42, Jim Blandy wrote: > >> Some possibly missing context: Mozilla Devtools wants to see this >> implemented for our own use. After much discussion last summer in London, >> the Firefox Devtools team decided to adopt the Chrome Debugging Protocol >> for the console and the JavaScript debugger. (The cases for converting the >> other tools like the Inspector are less compelling.) >> >> Speaking as the designer of Firefox's protocol, the CDP is a de-facto >> standard. The Firefox protocol really has not seen much uptake outside >> Mozilla, whereas the Chrome Debugging Protocol is implemented with varying >> degrees of fidelity by several different browsers. "Proprietary" is not the >> right term here, but in the sense of "used nowhere else", one could argue >> that it is Mozilla that is using the proprietary protocol, not Chrome. In a >> real sense, it is more consistent with Mozilla's mission for us to join the >> rest of the community, implement the CDP for the tools where it makes >> sense, and participate in its standardization, than to continue to push a >> protocol nobody else uses. >> > > I entirely agree that the current Firefox protocol is also proprietary. > However I also assumed that it's considered an internal implementation > detail rather than something we would expect people to interoperate with. > If that wasn't the case then I apologise: I should have complained earlier > :) > > Going forward, if we implement a "de-facto" standard that is not actually > standardised, we are assuming a large risk, in addition to the problems > around our stated values. An obvious concern is that Google are free to > change the protocol as they like, including in ways that are intentionally > or accidentally incompatible with other implementations. We also know from > past experience of implementing "de-facto" standards that implementation > differences end up hardcoded into third party consumers (i.e. web pages in > the case of DOM APIs), making it impossible to get interoperability without > causing intolerable short-term breakage. This has prevented standardisation > and compatibility of "de-facto" standards like innerText and > contentEditable, which remain nominally equivalent but actually very > different in all browsers. > > If people are starting to standardise not just the protocol but also the > semantics of CDP, that's great. But people tend to vastly underestimate how > long standardisation will take, and overestimate the resources that they > will find to work on it. So it would be good to see concrete progress > before we are actually shipping. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
