LGTM3, now is the time to make the change, before the old behavior is locked in by web compat.
On Mon, Sep 26, 2022 at 9:09 AM Mike West <[email protected]> wrote: > LGTM2, seconding Yoav's note to ensure that folks you know are using the > API test their code earlier rather than later to shake out bugs this > behavioral change might trigger. > > -mike > > On Saturday, September 24, 2022 at 7:00:17 AM UTC+2 Yoav Weiss wrote: > >> LGTM1 >> Seems good to make this change now, as usage is low, but rising. >> >> Please make sure you reach out to affected partners. >> >> On Fri, Sep 23, 2022 at 7:21 PM Daseul Lee <[email protected]> wrote: >> >>> >>> >>> On Fri, Sep 23, 2022 at 12:50 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Thu, Sep 22, 2022 at 8:06 PM 'Daseul Lee' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected] >>>>> >>>>> Specification >>>>> >>>>> >>>>> https://github.com/whatwg/fs/pull/53/commits/618b663ebdc0f9842d7db3091baed5f75aa87534 >>>>> >>>>> Summary >>>>> >>>>> Updates the asynchronous methods (`flush()`, `getSize()`, >>>>> `truncate()`) in `FileSystemSyncAccessHandle` in the File System Access >>>>> API >>>>> to synchronous methods. `FileSystemSyncAccessHandle` currently has a mix >>>>> of >>>>> sync and async methods, hindering the performance and the usability, >>>>> especially for applications porting C/C++ to Wasm. This update will bring >>>>> consistency in the API usage and improve the performance for Wasm-based >>>>> libraries. >>>>> >>>>> >>>>> Blink component >>>>> >>>>> Blink>Storage>FileSystem >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem> >>>>> >>>>> TAG review >>>>> >>>>> https://github.com/w3ctag/design-reviews/issues/772 >>>>> >>>>> TAG review status >>>>> >>>>> Pending >>>>> >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> Compatibility: >>>>> >>>>> Changing a return type from Promise to value can break, only if >>>>> Promise methods are directly used rather than `await`. However, we expect >>>>> minimal breakage due to very low usage (~0.00002% page loads; zero usage >>>>> queried via HttpArchive). >>>>> >>>> >>>> Do I understand correctly that this usage is a loose upper bound of >>>> users of the API, and not necessarily sites that are not using `await`? >>>> >>> Yes, that's correct. It includes any usage, whether it is `await` or >>> `Promise.then()` >>> >>> >>>> Does it include all the APIs that are planned to stop returning >>>> Promises? >>>> Also, can you link the use counter? >>>> >>> For truncate() method as an example, here is the link for use counter: >>> https://uma.googleplex.com/p/chrome/timeline_v2/?sid=33c4e21724eb85df0bdc19ff775d0018 >>> Unfortunately, it times out for (unique) count clients, so the above >>> link is filtered on Mac OX only. It is still very slow, though. >>> >> >> Thanks! >> Here are the public link for the same counters: >> Truncate - >> https://chromestatus.com/metrics/feature/timeline/popularity/4019 >> Flush - https://chromestatus.com/metrics/feature/timeline/popularity/4017 >> GetSize - >> https://chromestatus.com/metrics/feature/timeline/popularity/4018 >> >> >>> >>> Some other links: >>> Page load %: >>> https://chromestatus.com/metrics/feature/timeline/popularity/4019 >>> Additionally, we tried querying HttpArchive directly, and 0 usage has >>> returned. >>> >>> As a side note, we have an enterprise policy set up to guard this change >>> to prevent breakage. >>> >>>> >>>> >>>>> The original API was shipped in M102 and targeted for partner usage, >>>>> to which the changes may be communicated. In addition, all code snippets >>>>> and examples in public documents use `await`, which does not cause any >>>>> breakage. >>>>> >>>>> Interoperability: >>>>> >>>>> There are no interoperability risks expected. The design change was >>>>> initially proposed and assessed from vendor feedback. >>>>> https://github.com/whatwg/fs/issues/7 >>>>> >>>>> >>>>> Gecko: Positive ( >>>>> https://github.com/whatwg/fs/issues/7#issuecomment-1226562961) >>>>> >>>>> WebKit: No signal >>>>> >>>>> Web developers: Strongly positive ( >>>>> https://github.com/whatwg/fs/issues/7) >>>>> >>>>> Other signals: >>>>> >>>>> Ergonomics >>>>> >>>>> Low ergonomics risks are expected. In fact, the goal of this change is >>>>> to improve the ergonomics of the API by making all methods to return >>>>> synchronously and make it easier to use on Wasm-ported applications. >>>>> >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> Basic tooling: Autocomplete works as described in "New WebIDL/DOM >>>>> interfaces and attributes". >>>>> >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> No >>>>> >>>>> Desktop only now. Origin Private File System (including >>>>> `FileSystemSyncAccessHandle`) is planned to be shipped on Android in the >>>>> near future. >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Yes >>>>> >>>>> Flag name >>>>> >>>>> sync-access-handle-all-sync-surface >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> False >>>>> >>>>> Tracking bug >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1338340 >>>>> >>>>> Estimated milestones >>>>> >>>>> DevTrial on desktop >>>>> >>>>> 106 >>>>> >>>>> >>>>> Anticipated spec changes >>>>> >>>>> >>>>> https://github.com/whatwg/fs/pull/53/commits/618b663ebdc0f9842d7db3091baed5f75aa87534 >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5149644305203200 >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> 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/CAPscNz4GPefX650W7y-z2-kDVpwChCWur1UJb2490ySm03jy2A%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPscNz4GPefX650W7y-z2-kDVpwChCWur1UJb2490ySm03jy2A%40mail.gmail.com?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/165251ea-912f-480d-bc37-1758d5bede6en%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/165251ea-912f-480d-bc37-1758d5bede6en%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/CAARdPYd-d2FJ-kdsSj9vXKRsEPwEPowM7L2wSHYWMGkdgsHx_w%40mail.gmail.com.
