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: 
A similar issue was filed by Domenic Denicola from the Chrome team: 

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


> On Feb 5, 2021, at 9:15 AM, Emanuel Krivoy via webkit-dev 
> <webkit-dev@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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

webkit-dev mailing list

Reply via email to