LGTM2 under the same conditions, for one last extension here.
On Fri, Feb 11, 2022 at 11:14 AM Mike West <mk...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdtZgi5oaBbhfVhVTt5%2Be2UnW1E1d%3DPaA2iXu8ubkh_1g%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/CAL5BFfVKJKfWw-b3PWJLJiSBYHEcXOEFRHXbJQAe0JZSeogN6w%40mail.gmail.com.
