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 <https://groups.google.com/a/chromium.org/g/blink-dev/c/POsYbrXbL6I/m/Yfk5la0fBAAJ?utm_medium=email&utm_source=footer>, we have indeed created a new surface on OPFS (Access Handles <https://github.com/WICG/file-system-access/blob/main/AccessHandle.md>, currently in OT: I2E <https://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY>) 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 fived...@chromium.org, r...@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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage> Search tags storage <https://chromestatus.com/features#tags:storage>, nativeio <https://chromestatus.com/features#tags:nativeio>, performance <https://chromestatus.com/features#tags:performance>, low-level <https://chromestatus.com/features#tags:low-level>, generic <https://chromestatus.com/features#tags:generic>, foundation <https://chromestatus.com/features#tags: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 <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? 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 -- 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+unsubscr...@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.
