Intent to Extend Experiment: Storage Foundation API

[Emanuel Krivoy]

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, 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.

 

Please find the Chrome Status template below:

 

Contact emails

five...@chromium.org, rs...@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

Search tags

storage, nativeio, performance, low-level, generic, 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?

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

[Chris Harrelson]

Hi Emanuel,

A question inline below.

On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy <five...@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, 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?

 

--
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+...@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.

[Emanuel Krivoy]

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. 

[Mike West]

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

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.

[Yoav Weiss]

LGTM2 under the same conditions, for one last extension here.

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.

[Mike Taylor]

LGTM3 - agree with Mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVKJKfWw-b3PWJLJiSBYHEcXOEFRHXbJQAe0JZSeogN6w%40mail.gmail.com.