Contact emailsfive...@chromium.org, rs...@chromium.org
The Origin Private File System (OPFS, part of the File System Access API) is augmented with a new surface that brings very performant access to data. This new surface differs from existing ones by offering in-place and exclusive write access to a file’s content. This change, along with the ability to consistently read unflushed modifications and the availability of a synchronous variant on dedicated workers, significantly improves performance and unblocks new use cases.
TAG review statusPending
Interoperability and Compatibility
The feature has to be compatible with existing ways to access data on OPFS i.e., createWritable() and getFile(). The use of write locks and care for backwards compatibility should mean that the risk here is low. In order to ease compatibility concerns in the future, we've added an optional 'mode' parameter to createAccessHandle()/createSyncAccessHandle(). This allows us to eventually extend AccessHandle functionality to non-OPFS file systems without necessarily taking the OPFS behaviour as default (more details here: https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems).
There is a risk of interoperability between vendors, pending the position on implementing this surface. This design is the result of feedback from Gecko and WebKit, who reviewed previous iterations of this functionality and gave feedback that it should integrate more strongly with OPFS. We believe that the new design, when paired with a separate streams-based extension to OPFS, meets these goals. However, we have not yet received work back as to whether they agree with our assessment.Gecko
: No signal (https://github.com/mozilla/standards-positions/issues/562
: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html
: No signals
Goals for experimentationOur goal is to leverage partner “real life” use cases to verify the performance of the surface and find any bugs not caught by testing.
Ongoing technical constraints
While the main functionality has already landed, there are some missing features:
* There is no integration with storage quota yet.
* Writable streams are not yet locked when an access handle is created.
* The createSyncAccessHandle method doesn’t yet take the no-op ‘mode’ parameter.
Basic tooling: Autocomplete works as described in "New WebIDL/DOM interfaces and attributes".
Extended tooling: we'll eventually want to be able to explore files stored in OPFS. There are two tracking bugs related to this: crbug.com/256067 and crbug.com/735618. This API doesn't really add new storage backends, just new ways to interact with files, so we'd be covered by those as well.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No (File System Access API is not currently available on Android or Android WebView)Yes
Requires code in //chrome?False
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5702777582911488
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/33T36N6VBKI