[webkit-dev] Request for Position on Storage Foundation API

[Maciej Stachowiak]

We are not opposed to the concept of efficient access to files, but we are strongly opposed to minting a brand new Web API for file access instead of enhancing one of the existing ones.

This issue outlines the problem: https://github.com/fivedots/storage-foundation-api-explainer/issues/4 <https://github.com/fivedots/storage-foundation-api-explainer/issues/4>
A similar issue was filed by Domenic Denicola from the Chrome team: https://github.com/fivedots/storage-foundation-api-explainer/issues/8 <https://github.com/fivedots/storage-foundation-api-explainer/issues/8>

We strongly urge Chrome not to move forward with this API until the above issues are addressed in a satisfactory manner.

Regards,
Maciej

> On Feb 5, 2021, at 9:15 AM, Emanuel Krivoy via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> (Resending with correct subject for findability and to add further context. Sorry for the spam.)
> 
> Hello webkit-dev,
> 
> We would like to get an official position from WebKit on the Storage Foundation API (https://github.com/fivedots/storage-foundation-api-explainer <https://github.com/fivedots/storage-foundation-api-explainer>), 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.
> 
> The API is currently available behind a flag in Google Chrome. We've received feedback before in #4 (https://github.com/fivedots/storage-foundation-api-explainer/issues/4 <https://github.com/fivedots/storage-foundation-api-explainer/issues/4>), asking to clarify our relationship to other storage APIs. We are still working on gathering all the required data to resolve the issues raised there, we intend to update it as soon as we can.
> 
> Thank you,
> Emanuel Krivoy
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210205/6fd3b18b/attachment.htm>