Intent to Extend Experiment: Storage Foundation API

118 views
Skip to first unread message

Emanuel Krivoy

unread,
May 11, 2021, 1:05:32 PM5/11/21
to blink-dev, rs...@chromium.org, Yoav Weiss, Emanuel Ziegler

Hello blink-dev, 

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: 


Contact emails

five...@chromium.orgrs...@chromium.org

Explainer


https://github.com/WICG/storage-foundation-api-explainer

Specification

None

API spec

Yes

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

storagenativeioperformancelow-levelgenericfoundation

TAG review

https://github.com/w3ctag/design-reviews/issues/566

TAG review status

Pending

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 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)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

NativeIO

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=914488

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1143306

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


This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
May 17, 2021, 9:33:27 AM5/17/21
to Emanuel Krivoy, blink-dev, rs...@chromium.org, Yoav Weiss, Emanuel Ziegler
Since experimentation here started in M90, I'm reluctant to approve the experiment to go beyond M95. If you'd find that insufficient for current experimentation, please ask for another (short) extension once that milestone approaches.
Otherwise, I'm hoping that by then, the discussions on merging this with OPFS will yield us a different API shape.

So, LGTM to continue experimenting M93-M95.


--
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/CAHExSGJbnbfA290uGCLHbyEZyd68R_A4y%2B8CEqaA1U-0o0%3DOTg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages