Hey Emanuel, With my comments on the storage foundation I2E <https://groups.google.com/a/chromium.org/g/blink-dev/c/wDiMaUps4lg/m/kbGs31B5AQAJ> in mind, it looks like good, cross-vendor progress is being made on refining Access Handles' implementation and specification. There's clear engagement from partners who have begun using the feature in ways that give us confidence around it's broad shape and performance characteristics, and it seems reasonable to me to extend the trial out a bit to give folks time to hammer out the remaining details together.
LGTM to extend the experiment to 101. Ideally, that will allow y'all to bring the spec into shape, resolve any remaining disagreements about the API's behavior, and ensure our implementation matches those decisions. -mike On Wed, Jan 26, 2022 at 3:47 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > Would you be able to answer the questions Chris asked on the Storage > Foundation I2E? They seem relevant here as well. Thanks! :) > > On Thursday, January 20, 2022 at 4:06:34 PM UTC+1 Emanuel Krivoy wrote: > >> We’d like to ask for an extension to our Origin Trial, from M99 to M101. >> As mentioned in the Storage Foundation I2E >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/enA3o1UvzcE/m/qsaC_2whAQAJ>, >> our partner intended to run a final series of tests with the new surface, >> giving us a chance for to measure the impact of some of the design >> decisions (the effect of a mixed sync/async surface and of all filesystem >> operations being async). The tests were postponed and should happen in the >> near future, and so we’d like to extend the trial to be able to gather >> feedback from them. >> >> Please find the Chrome Status template below: >> >> Contact emails >> >> fived...@chromium.org, r...@chromium.org >> >> Explainer >> >> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md >> >> Specification >> >> WIP Draft: https://github.com/WICG/file-system-access/pull/344 >> >> 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 >> >> Closed, positive feedback. >> >> 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: 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. 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 >> >> 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 >> >> 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/64702163-232b-44f8-8d51-6ab763c7ea0fn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/64702163-232b-44f8-8d51-6ab763c7ea0fn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAKXHy%3Dcxj6qUhKJ5JYNFKRhp17P4AOrT_w6H7J%2B-%2B5wnBHCFzA%40mail.gmail.com.
