[w3ctag/design-reviews] Sync Methods for FileSystemSyncAccessHandle in File System Access API (Issue #772)

Wotcher TAG!

I'm requesting a TAG review of Sync Methods for FileSystemSyncAccessHandle in File System Access API.

`FileSystemSyncAccessHandle` is a file primitive that provides performant access to local files. One of its main use cases is applications porting C/C++ code to Wasm; however, asynchronous calls are not fully supported on Wasm yet, and using Asyncify library as an alternative has substantially degraded performance. Also, a split async/sync interface is not ergonomic, as Wasm-based applications expect a synchronous, POSIX-like file API.

Therefore, the proposal is to update asynchronous `getSize()`, `truncate()`, `flush()` and `close()` methods in `FileSystemSyncAccessHandle` in File System Access API to synchronous method, in line with synchronous `read()` and `write()` methods.

This change can potentially cause breakage if async methods were used the Promise .then()/.catch()/.finally() methods directly. (If used with `await`, there is no breakage). However, the current usage of `FileSystemSyncAccessHandle` is very low (e.g. zero usage queried by HttpArchive, recent shipping on Chrome-only); therefore, the scope and the impact of breakage is expected to be very minimal. Also, `FileSystemSyncAccessHandle` was shipped recently on Chrome M102 and is in the process of being implemented in Firefox, so it is preferred to make this change as soon as possible before the API gets used more widely.

  - Explainer: https://github.com/WICG/file-system-access/blob/main/AccessHandle.md

  - User research: N/A
  - Security and Privacy self-review²: https://github.com/WICG/file-system-access/blob/main/security-privacy-questionnaire.md

  - GitHub repo: [whatwg/fs](https://github.com/whatwg/fs/)
  - Primary contacts (and their relationship to the specification):
      - Austin Sullivan (@a-sully), Google Chrome
      - Daseul Lee (@dslee414), Google Chrome
  - Organization/project driving the design: Google/Chromium
  - External status/issue trackers for this feature: https://chromestatus.com/feature/5149644305203200


Further details:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - The group where the incubation/design work on this is being done (or is intended to be done in the future): whatwg (initial work was started WICG, but the relevant parts to this proposal have been moved to whatwg)
  - The group where standardization of this work is intended to be done ("unknown" if not known): whatwg
  - Existing major pieces of multi-stakeholder review or discussion of this design: 
https://github.com/whatwg/fs/issues/7

https://github.com/whatwg/fs/issues/28

  - Major unresolved issues with or opposition to this design:
  - This work is being funded by: Google

You should also know that...
- `FileSystemSyncAccessHandle` is available in Worker-only, thereby all synchronous calls are invoked from Workers, not from window.
- There is [ongoing discussion and developer demand](https://github.com/whatwg/fs/issues/41) around supporting an Async-version of access handle (name TBD for this performant file primitive). Note that this proposal is about making all methods sync within `FileSystemSyncAccessHandle`, and separately, we plan on supporting an async access handle, which may be more appropriate for common use cases, following asynchronous design patterns.


We'd prefer the TAG provide feedback as (please delete all but the desired option):
  💬 leave review feedback as a **comment in this issue** and @-notify [github usernames]
https://github.com/whatwg/fs/issues/7

@dslee414, @a-sully


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/772

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/772@github.com>