- ochameau, ato
These minutes are largely a summary, rather than an accurate depiction of what individuals said.
Path forward for DevTools
Questions are being asked about whether CDP at some point will replace RDP. At the moment the stated goal of CDP is not to replace RDP, but rather be a means for gaining Puppeteer support in Firefox. This means there are many CDP domains that are explicitly out of scope.
Moving DevTools from RDP to CDP is a DevTools matter that requires further evaluation, but concerns have been raised regarding code duplication between DevTools and the CDP-based remote agent. We might be able to reduce duplication to some extent by sharing functionality in ES modules, but this will realistically only be possible for simple features such as the Web Console.
For more complex features, such the RDP debugger component, it will be harder to reuse code effectively. If at a future point DevTools decides to move to CDP, it may make sense to fork it for the remote agent, bring its functionality up to parity with RDP, and then make the switch over.
Remaining work on prototype
Progress continues to be good, and work is ongoing in https://github.com/andreastt/gecko/tree/protocdp. The goal of this week is to finish a set of patches, and request review from the shared build peer queue.
There are largely three remaining tasks:
- Serve WebSockets from original HTTPD (ato)
- Remove custom EventEmitter.jsm in favour of toolkit’s (ochameau)
- Address original feedback from 1523104 (ochameau/ato)
Further progress largely depends on whether we will be able to fix the HTTPD problems. httpd.js is not really written for serving WebSocket connections, and the chrome-only
WebSocket.createWebSocketServer is not really written to take over a socket already accepted and manipulated by httpd.js. ato is adapting WebSocket.jsm to not read HTTP requests manually, but rather pass on request already parsed by httpd.js. Using various private fields for accessing the underlying input- and output streams we will—with some luck!—be able to make it assume control of the socket that httpd.js opened for us. One concern is that doing that will not let us serve multiple connections, but we will see.
Landing in central
ato met with ted and spoke to Mossop.
ted informed us there is no formal requirement for non-web standard features to send out intents-to-implement, but that it would be considerate to notify developers that a new, high-level feature has landed. Further, the module system is broken and we shouldn’t worry too much about it.
Mossop made us aware of some questions that developers will likely be interested in finding out from an intent. This includes whether it will ship in the default build, what the future of RDP is, what the security characteristics of the protocol are, and whether it will ship on Android/iOS.
Taking this feedback into consideration, we will proceed with our original plan, which is:
- Finish architectual work and prepare patches
- Request build peer review
- Land in central
- Send out intent-to-implement to dev-platform and firefox-dev
Intent to implement
It would be a good idea to start drafting the intent-to-implement this week, even if we are delaying to send it out. ato will draft an intent and request feedback from puppeteer-review.
There may be marketing concerns we should take into account.
- yulia and ochameau in Paris this week so we should aim to have a Vidyo meeting on Wednesday 27 February
- At this meeting we should decide what our regular meeting schedule should be
- ato away Tuesday 26 February
- ochameau away Friday 1 March