Contact emailsasu...@chromium.org, fived...@chromium.org, m...@chromium.org, r...@chromium.org
Explainer https://github.com/WICG/file-system-access/blob/main/AccessHandle.md Specification Summary 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. Included in this origin trial is also a version of the FileSystemHandle::move() method, currently limited to files in the OPFS only. The move() method will be shipped separately with its own intent ( https://chromestatus.com/feature/5640802622504960), but this limited subset is included in this origin trial because it significantly improves the performance and ease of use of the OPFS. Blink componentBlink>Storage>FileSystem <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/664 TAG review statusPending Risks 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 on official Request for Position ( https://github.com/mozilla/standards-positions/issues/562), but supportive of migrating the spec to whatwg (https://github.com/whatwg/sg/issues/176). WebKit: In development ( https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html) Request for position was not answered, but the feature is being implemented and is available in TP. See reference bug: https://bugs.webkit.org/show_bug.cgi?id=231185 Web developers: No signals Other signals: Goals for experimentation In general, we want to validate the new surface against "real world" use cases from our partners and developers at large. In particular, we are interested in the relative usage between the sync and async methods, since this could have an impact on performance when using Asyncify. We also would like to receive qualitative feedback on the ease of use of the API from within Wasm. Reason this experiment is being extended We're working with a partner, but they need more time to test and give feedback on the API. Ongoing technical constraints None Debuggability 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 Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ?Yes DevTrial instructions https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#trying-it-out Flag nameFileSystemAccessAccessHandle Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218431 Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1232436 Estimated milestones OriginTrial desktop last 102 OriginTrial desktop first 95 DevTrial on desktop 94 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5702777582911488 Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/33T36N6VBKI Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/_nB5VfgXW_I Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/-FVIvFovd3g/m/vUNm4X8UBAAJ 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnvaEUGDQN454DOppG3fb3b3Tp4VfHtEpYe_LWD10QnJ9016A%40mail.gmail.com.
