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 [email protected] wrote: > Thanks. Over the holidays I forgot that he'd already approved it. > > Reilly Grant | Software Engineer | [email protected] | Google Chrome > <https://www.google.com/chrome> > > > On Fri, Jan 8, 2021 at 2:58 PM Chris Harrelson <[email protected]> > wrote: > >> Yes, gapless LGTM, per what Mike said. >> >> On Fri, Jan 8, 2021 at 2:44 PM Reilly Grant <[email protected]> wrote: >> >>> Do API OWNERS approve the requested gapless transition from Origin Trial >>> to stable? >>> Reilly Grant | Software Engineer | [email protected] | Google Chrome >>> <https://www.google.com/chrome> >>> >>> >>> On Thu, Dec 17, 2020 at 12:21 PM Chris Harrelson <[email protected]> >>> wrote: >>> >>>> LGTM3 >>>> >>>> On Thu, Dec 17, 2020 at 12:00 PM Mike West <[email protected]> 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 [email protected] >>>>> 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 <[email protected]> >>>>>>> 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 | [email protected] | Google >>>>>>>> Chrome <https://www.google.com/chrome> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Dec 9, 2020 at 1:32 AM Fergal Daly <[email protected]> >>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>>> 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 | [email protected] | 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 [email protected]. >>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e64014d-2e4e-41be-8f6d-98d4281409a5n%40chromium.org.
