WebSerial support

[rrbutani]

what

We want to have the Web TUI support using the WebSerial API to communicate with actual devices in browsers that support it.

This is a tracking issue for this effort.

---

This is a large project that mostly involves making changes in external projects

• the WebSerial APIs are all async; this requires Control and the Transport APIs to be async when compiled for wasm: A conditionally async Control trait and RPC infra core#184
  • the fact that this infects a lot of the APIs in our codebase is unfortunate but there are no good alternatives to this, even if you're willing to resort to brittle WebWorker and SharedArrayBuffer methods of using the results of async code in sync code
• WebSerial is not yet in web-sys: Add WebSerial to web-sys/unstable APIs rustwasm/wasm-bindgen#2752

Within tui this will also necessitate large changes:

• Widget::update and Widget::render will need to become async to accommodate an async Control API. Perhaps these should become async on all platforms and not just wasm?
• Everything above Widget will need to become async too.

open questions

[rrbutani]

It may also be worth adding WebUSB support, both to the Web TUI as well as to devices.

This would let Android users use the TUI with devices; Chrome (and friends) on Android do not support WebSerial but do support WebUSB.

usbd-webusb would let us easily have devices expose themselves to WebUSB supporting devices and from there we can have the Web TUI use the existing USB CDC-ACM via WebSerial (where supported) or via a WebUSB based serial driver (like this one).

As detailed here, Android does not ship with a USB CDC-ACM class driver which is why we can use a WebUSB based driver to claim the existing serial device class. This means that the above strategy will not support browsers/platforms that:

• do not have WebSerial
• do have WebUSB
• do have a OS-level USB CDC-ACM class driver (preventing us from using WebUSB to register our own)
  • I'm assuming this is all platforms other than Android

In order to support such platforms we'd need to make our own USB class (which can be isomorphic to USB CDC-ACM) and probably have devices expose this alongside CDC-ACM so we don't drop support for existing serial based flows for the native TUI (necessitating that the native TUI use a custom USB class driver everywhere seems problematic and likely to cost us in terms of platform support).

This seems like a small niche anyways, just older Chrome/Edge/Opera versions: 61 to 88 for Chrome and Edge, 48 to 75 for Opera; ~1.25% of global usage as of this writing (as per caniuse).

Shipping our own custom USB class that we then use via WebUSB, in all browsers, while still retaining the USB CDC-ACM class for the native TUI, also doesn't seem worth the effort either (the list of platform considerations for using WebUSB are also somewhat daunting).