https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md
https://wicg.github.io/serial/
Yes.
The Serial API provides an interface for connecting to serial devices, either through a serial port on the user’s system or removable USB and Bluetooth devices that emulate a serial port. This API has been requested by the hardware developer community, especially developers building educational tools, as a companion to the WebUSB API because operating systems require applications to communicate with USB-based serial ports using their higher-level serial API rather than the low-level USB API. It also supports non-USB serial ports.
We are requesting a gapless transition from Origin Trial to stable release for the API in order to prevent developers from having to deploy non-web versions of their applications to cover the gap. Throughout the trial we have asked developers to adapt to changes in the API, to which they have been very responsive. There will be one more such change made as part of shipping, which is the following:
As of Chrome 89 the SerialConnectionEvent interface has been removed. When a “connect” or “disconnect” event is fired the target is the SerialPort interface itself (it bubbles to navigator.serial) and so the port can be accessed as e.target instead of e.port.
https://github.com/w3ctag/design-reviews/issues/431
Pending
https://docs.google.com/document/d/1vcjw-9q14Sr9v7ce3YR5gGzamykv_0Gbv4TDqGPdZCQ/edit
Gecko: Negative (https://mozilla.github.io/standards-positions/#webserial)
WebKit: Negative (https://webkit.org/tracking-prevention/)
Web developers: Strongly positive (https://discourse.wicg.io/t/serial-api-moving-from-web-of-sensors-cg-to-web-incubator-cg/2940)
Developers are able to debug script using this feature using the existing DevTools console and debugger. For debugging device communication issues it is often convenient to use the tee() method provided by the ReadableStream to split the streams going to or from the device and print them to the console for inspection.
Partially. WebIDL conformance and Permissions Policy tests are already upstreamed. More extensive Web Platform Tests have been prototyped in the Chromium wpt_internal directory and should be exportable to upstream Web Platform Tests by leveraging the work that Robert Ma has done on standardizing how we implement Mojo-based test-only APIs. This will be completed ASAP.
https://googlechromelabs.github.io/serial-terminal
https://chromestatus.com/feature/6577673212002304
Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/GcqEnSW5yHs/r7G3iMmDCQAJ
Intent to experiment #1:
https://groups.google.com/a/chromium.org/g/blink-dev/c/AiGJihoCbl4/m/OmA24108DwAJ
Intent to experiment #2:
https://groups.google.com/a/chromium.org/g/blink-dev/c/P5uKC_HTStw/m/VjYdUfg-BQAJ
Intent to experiment #3: https://groups.google.com/a/chromium.org/g/blink-dev/c/NGgprfPEbG0/m/nhNCiN0ZBgAJ
I've been acting as a Chromium specification mentor for this API, and am very happy with the quality of the resulting specification:
It's appropriately detailed and algorithmic, with every method and property specified through concrete steps. Reilly has paid close attention to commonly-missed spec issues like task queuing, error handling, or detailing which document or global object is involved in policy checks.
It integrates with and builds on Streams very well, using well-defined extension points and giving a detailed account of how an implementation should bridge from the OS-level serial port interfaces to the web-exposed streams APIs.
Although I am not a domain expert in serial communication, from what I can tell a lot of care seems to have gone into the API design, in terms of making it easy to use and integrating well with web platform primitives like promises and streams. The spec contains detailed examples showing how easy situations are relatively easy, and more complicated situations are no more complex than they need to be. A small example of this is issue #87.
It contains detailed security and privacy considerations sections which discuss the nuanced tradeoffs involved, with more details in the security and privacy questionnaire answers. (I've suggested moving a bit of useful information from the questionnaire answers into the spec's privacy considerations section.)
--
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/38f9b23b-2c71-4556-9337-e97b4f206b1en%40chromium.org.
LGTM2.Similar to the WebHID API, I'm happy with the work the team has done to address security and privacy concerns. The interaction model has proven effective, there's a good story around user-facing indicators, and we have the ability to cut off access to devices when that proves to be particularly dangerous. The implementation puts the user in control, and I'm excited to see it launch.
Thanks, Reilly! I framed this comment poorly, and I appreciate the clarification.I meant to convey my understanding is that serial-over-{USB,Bluetooth} runs any available vendor and product IDs through the same blocklist as WebUSB and Web Bluetooth, giving us some ability to mitigate risk for identifiable devices. Is that accurate?