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. The devtools.html JavaScript debugger already implements the Chrome protocol. We've implemented adapters like Valence that implement the Firefox protocol in terms of the Chrome protocol. So while it's true that not everything is documented at the standards of a WHATWG specification (yet), in practical terms, there hasn't been much problem getting things going. On Thu, Aug 31, 2017 at 2:50 AM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 31/08/17 02:14, Michael Smith wrote: > >> On 8/30/2017 15:56, David Burns wrote: >> > Do we know if the other vendors would see value in having this spec'ed >> properly so that we have true interop here? Reverse engineering seems like >> a "fun" project but what stops people from breaking stuff without realising? >> >> Fortunately we're not reverse engineering here (for the most part), all >> protocol messages are specified in a machine-readable JSON format which >> includes inline documentation [0] --- this is what the cdp Rust library >> consumes. The spec is versioned and the authors do seem to follow a proper >> process of introducing new features as "experimental", stabilizing mature >> ones, and deprecating things before they're removed. >> > > I think that the reverse engineering part is not the wire protocol, which > is usually the most trivial part, but the associated semantics. It doesn't > seem that useful to support the protocol unless we behave in the same way > as Chrome in response to the messages. It's the specification of that > behaviour which is — as far as I can tell — missing, and which seems likely > to involve reverse engineering. > > In general it seems unfortunate if we are deciding to implement a > proprietary protocol rather than opting to either extend something that is > already a standard (e.g. WebDriver) or perform standardisation work > alongside the implementation. What alternatives have we considered here? Is > it possible to extend existing standards with missing features? Or are the > current tools using the protocol so valuable that we don't have any choice > but to support them on their terms? If it's the latter, or we just think > the Chrome protocol is so technically superior to the other options that we > would be foolish to ignore it, can we work with Google to get it > standardised? I think some meaningful attempt at standardisation should be > a prerequisite to this kind of protocol implementation shipping in Firefox. > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
