Yes, this API is ready for production use. The specification may change but only in ways that align with our principles <https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines>, which focus on maintaining compatibility with existing web content. The folks on this thread who gave me the original LGTMs to ship this API will hold me to that. Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome <https://www.google.com/chrome>
On Thu, Sep 23, 2021 at 11:41 AM Nick Bond <nbond...@gmail.com> wrote: > Is this ready for production use now or is it still experimental? Will the > Spec change? > > Thanks! > > Nick > > On Wednesday, January 13, 2021 at 8:40:09 PM UTC-6 rei...@chromium.org > wrote: > >> Thanks. Over the holidays I forgot that he'd already approved it. >> >> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome >> <https://www.google.com/chrome> >> >> >> On Fri, Jan 8, 2021 at 2:58 PM Chris Harrelson <chri...@chromium.org> >> wrote: >> >>> Yes, gapless LGTM, per what Mike said. >>> >>> On Fri, Jan 8, 2021 at 2:44 PM Reilly Grant <rei...@chromium.org> wrote: >>> >>>> Do API OWNERS approve the requested gapless transition from Origin >>>> Trial to stable? >>>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome >>>> <https://www.google.com/chrome> >>>> >>>> >>>> On Thu, Dec 17, 2020 at 12:21 PM Chris Harrelson <chri...@chromium.org> >>>> wrote: >>>> >>>>> LGTM3 >>>>> >>>>> On Thu, Dec 17, 2020 at 12:00 PM Mike West <mk...@chromium.org> wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> With regard to the gapless OT, there's good evidence of developer >>>>>> feedback, and equally good evidence that the API has changed in response. >>>>>> Given that we have confidence in the shape of the API, it seems >>>>>> reasonable >>>>>> to me to move it directly from OT to stable without enforcing a gap in >>>>>> availability. So, that bit specifically LGTM. >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> >>>>>> On Thursday, December 17, 2020 at 8:23:35 PM UTC+1 yo...@yoav.ws >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> *LGTM1* >>>>>>> >>>>>>> This seems like an important addition to the web platform, that >>>>>>> enables unique use-cases >>>>>>> <https://joreteg.com/blog/project-fugu-a-new-hope#so-what-specific-capabilities-do-i-need-that-web-doesn39t-yet-provide> >>>>>>> that were previously reserved to native apps, with their associated >>>>>>> deployment pain. Thanks for working on this!! >>>>>>> >>>>>>> On Friday, December 11, 2020 at 5:34:51 AM UTC+1 Fergal Daly wrote: >>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> On Thu, 10 Dec 2020 at 07:07, Reilly Grant <rei...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I've met with the BFCache team to figure out how to support >>>>>>>>> BFCache with WebUSB, and supporting it with Web Serial will have >>>>>>>>> similar >>>>>>>>> challenges. I've filed https://github.com/WICG/serial/issues/109 >>>>>>>>> to track defining the integration points so that we can avoid >>>>>>>>> continuing to >>>>>>>>> blocklist all pages that are using Web Serial as we currently do. >>>>>>>>> Reilly Grant | Software Engineer | rei...@chromium.org | Google >>>>>>>>> Chrome <https://www.google.com/chrome> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Dec 9, 2020 at 1:32 AM Fergal Daly <fer...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> [+bfcache-dev] >>>>>>>>>> >>>>>>>>>> Hi Reilly, >>>>>>>>>> >>>>>>>>>> how does WebSerial interact with Chrome's BFCache >>>>>>>>>> <https://web.dev/bfcache/>? Can we make it so that a page that >>>>>>>>>> has an open serial connection can safely be put into BFCache and >>>>>>>>>> will work >>>>>>>>>> when it comes out without breaking user expectations (that they had >>>>>>>>>> navigated away from the page)? If not, we need to ensure that pages >>>>>>>>>> using >>>>>>>>>> WebSerial do not go into BFCache when it would be a problem. >>>>>>>>>> >>>>>>>>>> We have put together a doc >>>>>>>>>> <https://docs.google.com/document/d/1kR9QHWXXpoXsP3Y6JEDpIgZ5p7EgTTvdDN2kIrYdXcg/edit#> >>>>>>>>>> that >>>>>>>>>> hopefully provides enough information for feature teams to figure >>>>>>>>>> this out. >>>>>>>>>> Could you take a look and figure out what issues there may be? It's >>>>>>>>>> a new >>>>>>>>>> doc so feedback on the doc itself is also appreciated. >>>>>>>>>> >>>>>>>>>> The simplest course of action is to blocklist all pages that use >>>>>>>>>> WebSerial but ideally we can ensure that they work well together. >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> F >>>>>>>>>> On Saturday, December 5, 2020 at 10:16:03 AM UTC+9 Reilly Grant >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emails >>>>>>>>>>> >>>>>>>>>>> rei...@chromium.org >>>>>>>>>>> >>>>>>>>>>> Explainer >>>>>>>>>>> >>>>>>>>>>> https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md >>>>>>>>>>> >>>>>>>>>>> Specification >>>>>>>>>>> >>>>>>>>>>> https://wicg.github.io/serial/ >>>>>>>>>>> >>>>>>>>>>> API spec >>>>>>>>>>> >>>>>>>>>>> Yes. >>>>>>>>>>> >>>>>>>>>>> Design docs >>>>>>>>>>> >>>>>>>>>>> https://web.dev/serial/ >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Blink component >>>>>>>>>>> >>>>>>>>>>> Blink>Serial >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESerial> >>>>>>>>>>> >>>>>>>>>>> TAG review >>>>>>>>>>> >>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/431 >>>>>>>>>>> >>>>>>>>>>> TAG review status >>>>>>>>>>> >>>>>>>>>>> Pending >>>>>>>>>>> >>>>>>>>>>> Link to origin trial feedback summary >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://docs.google.com/document/d/1vcjw-9q14Sr9v7ce3YR5gGzamykv_0Gbv4TDqGPdZCQ/edit >>>>>>>>>>> >>>>>>>>>>> Risks >>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> Debuggability >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Tracking bug >>>>>>>>>>> >>>>>>>>>>> https://crbug.com/884928 >>>>>>>>>>> >>>>>>>>>>> Launch bug >>>>>>>>>>> >>>>>>>>>>> https://crbug.com/967863 >>>>>>>>>>> >>>>>>>>>>> Sample links >>>>>>>>>>> >>>>>>>>>>> https://googlechromelabs.github.io/serial-terminal >>>>>>>>>>> >>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>> >>>>>>>>>>> https://chromestatus.com/feature/6577673212002304 >>>>>>>>>>> >>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>> <https://www.chromestatus.com/> and edited by hand. >>>>>>>>>>> Reilly Grant | Software Engineer | rei...@chromium.org | Google >>>>>>>>>>> Chrome <https://www.google.com/chrome> >>>>>>>>>>> >>>>>>>>>> -- >>>>>> 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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38f9b23b-2c71-4556-9337-e97b4f206b1en%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMbH7P0R9vzRojjJgC0%3DvQAVh6MNWBpwGawdc55_xq1PDA%40mail.gmail.com.
