FYI: updated our documentation accordingly (PR <https://github.com/GoogleChrome/web.dev/pull/6241>).
On Thu, Sep 9, 2021 at 1:40 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > LGTM to experiment M95-M98 > > On Wednesday, September 8, 2021 at 9:40:41 AM UTC+2 Emanuel Krivoy wrote: > >> Contact emails >> >> fived...@chromium.org, r...@chromium.org >> >> Explainer >> >> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md >> >> Specification >> >> Work in progress. See explainer for WebIDL definition. >> >> 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-Experiment 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 >> >> Preliminary positive feedback, pending closure after plenary session. >> >> 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: No formal signal, but generally positive reception with questions >> about supporting existing surfaces ( >> https://github.com/mozilla/standards-positions/issues/562) >> >> WebKit: No signal ( >> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html) >> >> 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. The current implementation in >> Chrome is currently being tested by partners to confirm it is a good >> replacement of Storage Foundation for their needs. >> >> 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>. >> >> 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. >> >> 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 (in particular >> for locking semantics). 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 >> >> Is this feature supported on all six Blink platforms? >> >> No. File System Access API is not currently available on Android or >> Android WebView. >> >> 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 >> >> Access Handles >> >> OriginTrial desktop last >> >> 98 >> >> 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 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 >> >> >> This intent message was mostly generated by Chrome Platform Status >> <https://www.chromestatus.com/>. >> >> -- Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.23 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. hTtPs://xKcd.cOm/1181/ -----END PGP SIGNATURE----- -- 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/CALgRrLn70%2BSjgxZ5cdPHi5XJRdQus19n9OoHwe1yP9YrX2oSmw%40mail.gmail.com.
