Hello blink-dev, five...@chromium.org, rs...@chromium.org
We'd like to extend our ongoing origin trial to include the M93-M96 period. Please find the template created by chrome status with our reasoning below:
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.
Search tagsstorage, nativeio, performance, low-level, generic, foundation
TAG review statusPending
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 accessWebKit
: 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 are actively working with a partner that is running internal betas of their product. These tests will continue for next few releases (from M93 to M96), and have been a source of useful feedback so far. We’d like to continue supporting their experimentation during this same period. We are currently in discussions with other vendors to merge the functionality of Storage Foundation into the Origin Private File System of the File System Access API (more details here: <https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec>), and their developer and user feedback will be useful when seeking consensus on the shape of the new surface.
So far we’ve gotten feedback on the quota system and overall usefulness of the API (as well as more context on the sync vs. async question and issues with ArrayBuffer transfers). Continuing the experiment will provide more feedback and validation from real users as the partner’s tests keep growing in scope and user base. It will also allow us to get comparative feedback between Storage Foundation and prototypes of the merged surface.
Ongoing technical constraints
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?YesYes
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5670244905385984
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/gh0gTHO18YQIntent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY