Thanks for working on this important capability!! On Tuesday, March 22, 2022 at 5:24:08 PM UTC+1 Emanuel Krivoy wrote:
> 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. > So the plan is to land the PR in WICG, and then (immediately) move it over to https://fs.spec.whatwg.org/? What are the current blockers for the WICG PR from landing? > 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 > Have you tried running STP against the WPT test suite? That could be reassuring interop-wise > > 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> > > Thanks for a very strong developer signal! > > 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/7ede86dc-9d4f-4c02-82a2-230ca2f67662n%40chromium.org.
