On Thursday, August 31, 2017 at 2:51:41 AM UTC-7, James Graham 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? > > > 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.
For more history on executing on a de-facto standard; remotedebug.org was started as an effort to spec the protocol by representatives from Edge, Chrome and Firefox. Chrome committed to keeping the stable parts of the API stable, which so far worked. For comparison, WebDriver has gone a similar route, experimenting in the open while standardized the stable parts of the API. To the idea of having one tool like Web Driver solving all remote debug needs: Having WebDriver focussed on Automation and not on matching CDP's more advanced use cases avoid reinventing the wheel. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
