Intent to Extend Experiment: Storage Foundation API

108 views
Skip to first unread message

Emanuel Krivoy

unread,
Sep 29, 2021, 11:35:48 AM9/29/21
to blink-dev, Yoav Weiss, ecmzi...@chromium.org, rs...@chromium.org

Hello blink-dev,

We’d like to ask for one last extension to our Origin Trial, from M96 to M98. As mentioned in our previous I2E, we have indeed created a new surface on OPFS (Access Handles, currently in OT: I2E)  that covers the use cases of 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.


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

95 (would be 98 if approved)

OriginTrial desktop first

90


OriginTrial android last

95 (would be 98 if approved)

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

unread,
Sep 30, 2021, 3:24:43 PM9/30/21
to Emanuel Krivoy, blink-dev, Yoav Weiss, ecmzi...@chromium.org, rs...@chromium.org
LGTM

--
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/CAHExSGK2dgYcy%2Bu_tNvUmj_6Uv15X3AobAh7NnMA-%2BMYZ0id4g%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages