Hello blink-dev, We'd like to request a review on our intent to ship Access Handles with Chrome 101. Since we don't envision changes to the surface and it is currently in use by Photoshop web, this request comes one release before our OT expires. Please find the details below: Contact emails
fived...@chromium.org, r...@chromium.org Explainer https://github.com/WICG/file-system-access/blob/main/AccessHandle.md Specification Out for review. <https://github.com/WICG/file-system-access/pull/344/files> Will be moved <https://github.com/WICG/file-system-access/issues/342> to WHATWG after replying to pending comments. 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 (especially for porting existing IO-heavy applications to WebAssembly). This Intent-to-Ship is only in reference to the sync variant of the API i.e., the createSyncAccessHandle() method and the SyncAccessHandle object (only exposed in worker contexts): const handle = await file.createSyncAccessHandle(); var writtenBytes = handle.write(buffer); var readBytes = handle.read(buffer {at: 1}); The sync variant is meant to be consumed by low-level entities like toolchains. We expect application developers to prefer the async API with its streaming interface which will be shipped later. AccessHandles is the new API shape for what was previously called Storage Foundation API (Intent-to-Experiment: http://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY). 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/664 TAG review status Issues addressed 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 directly shared documents outlining alternatives considered <https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec>, and later our recommendation <https://docs.google.com/document/d/1g7ZCqZ5NdiU7oqyCpsc2iZ7rRAY1ZXO-9VoG4LfP7fM> towards this particular API shape. We believe that the new design, when paired with a separate streams-based extension to OPFS, meets the goal of more strongly integrating with the existing surface. However, we have not yet received replies to the position requests below. Gecko: Worth Prototyping ( https://github.com/mozilla/standards-positions/issues/562) 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: Positive >From our Storage Foundation OT, we received very positive feedback on the need for high performance storage, as well as on the general shape of the API: - Adobe’s support statement (about the need for the capability) <https://github.com/WICG/proposals/issues/10#issuecomment-804145429> - absurd-sql’s mention <https://github.com/mozilla/standards-positions/issues/481#issuecomment-898061119> - Reception on Twitter after DevRel announcement <https://twitter.com/ChromiumDev/status/1405101909757902851> SyncAccessHandles have a very similar shape to the surface that was exposed in Storage Foundation’s Origin Trial. It is currently a critical dependency <https://web.dev/ps-on-the-web/#high-performance-storage> of Photoshop Web. The Photoshop team has confirmed that the current surface covers their needs and that they have no pending feedback/requests. Ergonomics As mentioned above, SyncAccessHandles offer a very similar surface to the one positively received during Storage Foundation’s OT. The main differences are the migration of file system operations into OPFS and the asynchronicity of auxiliary methods (i.e. methods other than read and write). Since many of our use cases require good interoperability between this API and Wasm, we’ve developed an Emscripten file system <https://github.com/rstz/emscripten-pthreadfs/tree/main/pthreadfs> that allows ported applications to use SyncAccessHandles. This simplifies both activation and use, since the API can be accessed through standard C/C++ file system libraries. Security and Privacy SyncAccessHandles have received approval for Security and Privacy in our launch bug <https://bugs.chromium.org/p/chromium/issues/detail?id=1232436>. 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. File System Access API usage is also reflected in user settings pages such as chrome://settings/siteData. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? Yes, we’ve added tests for all new functionality, as well as for the intersection between this surface and existing parts of OPFS, e.g., we’ve made sure that locking between writables and access handles is correct. Our test suite is also run against our Incognito mode implementation, since it is significantly different from the regular mode one. wpt.fyi results: wpt.fyi/results/file-system-access?label=master&label=experimental&aligned Is this feature supported on all six Blink platforms? Not yet. File System Access API is not yet available on Android or Android WebView, but the Storage team has expressed interest <https://bugs.chromium.org/p/chromium/issues/detail?id=1011535#c9> in at least enabling OPFS once there is more usage/cross-browser support. Demo The API has no UI component. An example code snippet can be found here <https://github.com/WICG/file-system-access/blob/access-handle-spec/AccessHandle.md#new-data-access-surface> . DevTrial instructions https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#trying-it-out Flag name FileSystemAccessAccessHandle Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1218431 Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1232436 Estimated milestones OriginTrial desktop last 102 OriginTrial desktop first 95 DevTrial on desktop 94 We aim to ship with 101. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5702777582911488 Links to previous Intent discussions Intent 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 Intent to Extend Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGL4tBM-mH%2B-Cm7YtBiVMLLGrPMVxtCHYwG6PM_oG67hjw%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cahexsgl4tbm-mh+-cm7ytbivmllgrpmvxtchywg6pm_og67...@mail.gmail.com> This intent message was generated by Chrome Platform Status <https://www.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/CAHExSGJ8GEas8A2gbdnjSS-%2BNKepOB0ZQGdinCTckmRDBgPaAw%40mail.gmail.com.
