Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage Foundation API #481

Closed
fivedots opened this issue Feb 4, 2021 · 4 comments
Closed

Storage Foundation API #481

fivedots opened this issue Feb 4, 2021 · 4 comments
Labels
venue: Proposal Proposal not associated with a community group or standards org

Comments

@fivedots
Copy link

fivedots commented Feb 4, 2021

Request for Mozilla Position on an Emerging Web Specification

Other information

This feature is being prototype in Google Chrome and had gone through an early TAG design review. It has been presented TPAC 2020 (WebApps WG minutes, breakout).

@annevk
Copy link
Contributor

annevk commented Feb 8, 2021

While in principle it seems reasonable to have a low-level storage API, WICG/storage-foundation-api-explainer#4 and WICG/storage-foundation-api-explainer#8 are problematic and I don't think it's an acceptable outcome for the web platform to have that many ways to work with files. (I know there is some hope for removal of File and Directory Entries API, but that does not seem sufficient, if it even works out.) I think this really needs a more holistic approach to what a filesystem API might look like that is both nice to work with, performant, and appreciative of the status quo across browsers.

cc @asutherland

@annevk annevk added the venue: Proposal Proposal not associated with a community group or standards org label Feb 8, 2021
@svoisen
Copy link

svoisen commented Mar 23, 2021

Hi @annevk @asutherland — I just wanted to make you aware of a position of support for Storage Foundation that we (at Adobe) posted: WICG/proposals#10 (comment)

We understand that there is some concern about the splintering of APIs and multiple ways of working with files. At the same time, we also need the performance properties it provides, which are presently lacking in existing solutions or File System Access. I'm hoping that we might be able to nudge some more discussion on a solution that would be acceptable to all.

@birtles
Copy link
Member

birtles commented Aug 13, 2021

Former Mozilla engineer @jlongster just released absurd-sql and suggests this API (or presumably something of its ilk) is a necessary piece for achieving database performance that is more competitive with native.

@annevk
Copy link
Contributor

annevk commented Aug 30, 2021

Let's fold this into #562.

@annevk annevk closed this as completed Aug 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
venue: Proposal Proposal not associated with a community group or standards org
Projects
None yet
Development

No branches or pull requests

4 participants