Intent to Ship: Sync methods for FileSystemSyncAccessHandle in File System Access API

[Daseul Lee]

Contact emails

ds...@google.com

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

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). 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?

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.

[Yoav Weiss]

On Thu, Sep 22, 2022 at 8:06 PM 'Daseul Lee' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ds...@google.com

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

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`?

Does it include all the APIs that are planned to stop returning Promises?

Also, can you link the use counter?

 

--
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/CAPscNz4GPefX650W7y-z2-kDVpwChCWur1UJb2490ySm03jy2A%40mail.gmail.com.

[Daseul Lee]

On Fri, Sep 23, 2022 at 12:50 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Sep 22, 2022 at 8:06 PM 'Daseul Lee' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ds...@google.com

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

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.

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.

[Yoav Weiss]

LGTM1

Seems good to make this change now, as usage is low, but rising.

Please make sure you reach out to affected partners.

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

[Mike West]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM3, now is the time to make the change, before the old behavior is locked in by web compat.

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/CAPscNz4GPefX650W7y-z2-kDVpwChCWur1UJb2490ySm03jy2A%40mail.gmail.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 blink-dev+...@chromium.org.
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.