Intent to Extend Experiment: Storage Foundation API
Emanuel Krivoy
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
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
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
--
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.