Hey Emanuel, API owners discussed this intent this week and the week before, with a fair amount of skepticism around the length of the experimentation (April 2021 (90) - May 2022 (101)), and the value of continuing this experiment in light of what looks like reasonable alignment from our colleagues in WebKit and Gecko on the Access Handles proposal which y'all are working through in parallel. With that in mind, the best path forward would be to let this experiment expire rather than extending it. Unfortunately, it appears that some miscommunication led a partner to begin relying on this API in ways that make it difficult for us to simply remove support. This puts us in a bit of a pickle.
I'd like to ensure that we don't end up in this situation again in 3 months if we extend this OT to give the partner time to migrate off of Storage Foundation. I think we have solid commitments from them that they'll be able to shift onto Access Handles in the timeframe we're discussing, and I think we can strengthen that encouragement by allowing them to extend their OT tokens once, and then disabling new signups for the OT to ensure that new partners don't accidentally land on this instead of Access Handles. That's a compromise that seems to me to minimize the incremental risk of burn-in, while allowing us to remove this API from the platform without user-visible breakage. But it's an unusual extension, so I don't think a single LGTM is sufficient to approve it. LGTM1 to extend the trial to 101 _and_ disable new signups or renewals. Ideally, the partner can complete their migration before 101, in which case we can end the trial earlier. I'd appreciate other API owners weighing in. -mike On Tue, Feb 1, 2022 at 4:55 PM Emanuel Krivoy <fived...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGJ_Eeu_iONJ9ajZ3%2BQj-_RZ%2BDC7r_Ng_6etEQY479Ak2A%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/CAKXHy%3DdtZgi5oaBbhfVhVTt5%2Be2UnW1E1d%3DPaA2iXu8ubkh_1g%40mail.gmail.com.
