Requesting Eng Review: Async Command Processing for WebDriver in Chromium

151 views
Skip to first unread message

Brandon Walderman

unread,
Nov 18, 2020, 4:45:03 PM11/18/20
to blink-dev, mt...@google.com
Hi blink-dev,

The ChromeDriver implementers have recently been investigating solutions to implement the new WebDriver BiDi protocol. One solution we are exploring is Rust. WebDriver BiDi and CDP are both asynchronous protocols, and a ChromeDriver BiDi implementation written using Rust’s async/await syntax would likely be easier to write and maintain long term as compared to other possible solutions that stick to C++. I’ve written a design document outlining the motivation for considering Rust and how this approach would work. The document is available here:


I’d like to request an engineering review of this design. I understand that Rust is not generally approved for widespread use in Chromium per the coding guidelines, however I'd like to ask if it could be approved for our scenario. This is not yet an intent to prototype or ship. Looking forward to hearing your thoughts.

Thanks!

Brandon Walderman
Microsoft Edge Developer Tools Team

Darin Fisher

unread,
Nov 19, 2020, 11:57:30 AM11/19/20
to Brandon Walderman, blink-dev, mt...@google.com
Hi Brandon,

Thank you for the thoughtful write-up. There certainly is complexity in asynchronous programming, and I for one appreciate proposals on how to simplify. That said, I don't think this is a strong enough case to warrant adding a new language, in this case Rust, to Chromium.

While Rust may be a great tool for this use case, and the folks working in this area may feel good about using Rust, the reality is that we have to think about the larger code base and all of the engineers who are contributing to Chromium. This is why the code guidelines say to stick to the current set of supported languages. Just to repeat what it says:

While there is likely always a slightly better tool for any particular job, maintainability of the codebase is paramount. Reducing the number of languages eases toolchain and infrastructure requirements, and minimizes the learning hurdles for developers to be successful contributing across the codebase.

Just to put that into perspective, I think it is important that we avoid unintentional barriers to contributions and to developers working on, say, ChromeDriver. If developers have to master a new language in order to do so, then that is a non-trivial barrier. We have to ask ourselves if that is worth it for the benefits of using that new language in such an instance.

To me the bar is very high to introduce a new language to Chromium. It has to be worth the cost for everyone to learn and worth the cost of everyone having to master not just that new language but also the existing language. There's no story for eliminating C++ in favor of Rust, so adding Rust means we have to support both.

My recommendation is to lean into the fact that Chromium is largely a C++ based project and work on improvements on how we do asynchronous programming to address the core issues that motivate you to consider Rust. I'm sure there are incremental and meaningful improvements we could make.

Again, I appreciate your thoughtfulness on this topic.

Thanks!
-Darin

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6fb76234-0535-411c-8008-00d5c98cf1edn%40chromium.org.

Brandon Walderman

unread,
Nov 23, 2020, 5:50:20 PM11/23/20
to blink-dev, Darin Fisher, blink-dev, Mathias Bynens, Brandon Walderman
Thanks Darin for taking a look and for the prompt reply. It looks like we'll move forward with a C++ approach. That likely means using callback-passing style code for the near future. For the longer term we can certainly look into some of the incremental improvements mentioned in the doc, such as promises and coroutines.

Brandon

Reply all
Reply to author
Forward
0 new messages