Hi Chris, Replies inline as well:
Is it accurate to say then that there hasn't been substantial use on sites > recently? Or are they using it generally but just haven't run the set of > tests yet? > The latter, Photoshop Web used Storage Foundation generally, and is now using Access Handles. Another partner has started a set test on their project, which would include feedback on the difference between the APIs from the perspective of new use cases. Also, could you summarize the feedback from partners so far on this origin > trial? > Feedback from partners has been very positive: Photoshop Web reported that both APIs critically unblocked their site, and did not see significant impact after transitioning to Access Handles. They use the API as a general purpose storage backend that can be performantily/easily accessed from Wasm, as well as a way to manage memory consumption during image editing. The other partner is also relying on Storage Foundation for critical bits of their project, although we've gotten less detailed feedback so far. On Thu, Jan 20, 2022 at 6:44 PM Chris Harrelson <chris...@chromium.org> wrote: > Hi Emanuel, > > A question inline below. > > On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy <fived...@chromium.org> > wrote: > >> Hello blink-dev, >> >> >> >> We’d like to ask for an extension to our Origin Trial, from M99 to M101. >> As mentioned in our previous 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 that would allow us to >> measure the impact of the changes between Storage Foundation and its >> successor Access Handles. The tests were postponed but should happen in the >> near future, therefore we’d like to continue having concurrent Access >> Handle/Storage Foundation trials. >> > > Is it accurate to say then that there hasn't been substantial use on sites > recently? Or are they using it generally but just haven't run the set of > tests yet? > > Also, could you summarize the feedback from partners so far on this origin > trial? > > >> >> >> Please find the Chrome Status template below: >> >> >> >> Contact emails >> >> fived...@chromium.org, r...@chromium.org >> >> Explainer >> >> https://github.com/WICG/storage-foundation-api-explainer >> >> Specification >> >> N/A >> >> Summary >> >> Storage Foundation API is a storage API that resembles a very basic >> filesystem, with direct access to stored data through buffers and offsets. >> Our goal is to give developers flexibility by providing generic, simple, >> and performant primitives upon which they can build higher-level >> components. It's particularly well suited for Wasm-based libraries and >> applications that want to use custom storage algorithms to fine-tune >> execution speed and memory usage. >> >> >> Blink component >> >> Blink>Storage >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage> >> >> Search tags >> >> storage <https://chromestatus.com/features#tags:storage>, nativeio >> <https://chromestatus.com/features#tags:nativeio>, performance >> <https://chromestatus.com/features#tags:performance>, low-level >> <https://chromestatus.com/features#tags:low-level>, generic >> <https://chromestatus.com/features#tags:generic>, foundation >> <https://chromestatus.com/features#tags:foundation> >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/566 >> >> TAG review status >> >> Closed >> >> Risks >> >> Interoperability and Compatibility >> >> This new feature has some potential interoperability risks due to its >> nature as a novel and low-level API. Currently, there are no web features >> that expose such a generic interface and that focus on WebAssembly ports as >> one of it's main consumers. >> >> We've also received feedback from other vendors that the functionality >> added in Storage Foundation API seems duplicative of File System Access >> API. We are exploring a merged design (details here: >> https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec) >> while collecting feedback and validating design choices with this >> independent API. >> >> >> Gecko: Negative ( >> https://github.com/mozilla/standards-positions/issues/481) Supportive of >> a low-level storage API, opposed to minting a new API instead of taking a >> holistic approach to file access >> >> WebKit: Negative ( >> https://lists.webkit.org/pipermail/webkit-dev/2021-February/031687.html) >> No opposition to offering efficient access to files, strongly opposed to >> minting a new API instead of augmenting an existing one. >> >> Web developers: No signals >> >> >> Goals for experimentation >> >> In general, we would like to validate the whole surface of our API >> against developer expectations and more diverse use cases. In particular, >> we are interested in confirming that we provide the required performance to >> allow new uses, and to shed light on developer preference between a >> synchronous and asynchronous surface. >> >> Reason this experiment is being extended >> >> We added a new surface on OPFS (Access Handles: >> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md) >> that replaces Storage Foundation. Having concurrent trials would help us >> validate the surface by comparing and contrasting it with the previous one. >> Our partner will run a final series of tests with beta users, and this >> provides a chance for us to measure the impact of some of the design >> decisions we’ve made. In particular we’d like to see the effect of >> providing a mixed sync/async surface on SyncAccessHandles and of all >> filesystem operations being async. Concurrent trials would also make it >> easier to measure any unexpected performance differences. >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)? >> >> Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> >> Flag name >> >> NativeIO >> >> Requires code in //chrome? >> >> False >> >> Tracking bug >> >> https://bugs.chromium.org/p/chromium/issues/detail?id=914488 >> >> Launch bug >> >> https://bugs.chromium.org/p/chromium/issues/detail?id=1143306 >> >> Estimated milestones >> >> OriginTrial desktop last >> >> 98 >> >> OriginTrial desktop first >> >> 90 >> >> OriginTrial android last >> >> 98 >> >> OriginTrial android first >> >> 90 >> >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5670244905385984 >> >> Links to previous Intent discussions >> >> Intent to prototype: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/gh0gTHO18YQ >> >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY >> >> -- >> 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/CAHExSGLmxBWbT2vuLX_cVWn8wrzqSF0w0bvN5dTkdYc0T63%3Dig%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGLmxBWbT2vuLX_cVWn8wrzqSF0w0bvN5dTkdYc0T63%3Dig%40mail.gmail.com?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/CAHExSGJ_Eeu_iONJ9ajZ3%2BQj-_RZ%2BDC7r_Ng_6etEQY479Ak2A%40mail.gmail.com.
