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

Add KV Storage Built In Module #1923

Closed
kitsonk opened this issue Mar 12, 2019 · 8 comments
Closed

Add KV Storage Built In Module #1923

kitsonk opened this issue Mar 12, 2019 · 8 comments

Comments

@kitsonk
Copy link
Contributor

kitsonk commented Mar 12, 2019

In Chromium 74, KV Storage has been implemented as a built-in module. The module is a far more rational API than IndexDB (and local storage).

The WICG draft is located here: https://wicg.github.io/kv-storage/

This would require #1922

This could negate the need for #1699

@kitsonk
Copy link
Contributor Author

kitsonk commented Mar 13, 2019

Actually reading the spec further, it is actually a standard modern API layer on top of IndexDB and uses IndexDB to persist the storage. So #1699 is a requirement before we could implement this.

@afinch7
Copy link
Contributor

afinch7 commented Mar 13, 2019

Doesn't mean that we have to implement it like that.

@kitsonk
Copy link
Contributor Author

kitsonk commented Mar 13, 2019

Well, if you look at the spec, there is a expected back off to IndexedDB where you can gain access to the db instance for advanced usage.

@afinch7
Copy link
Contributor

afinch7 commented Mar 13, 2019

They way you put it the first time it sounded like it was just a implementation choice, but no it actually exists in the spec https://wicg.github.io/kv-storage/#storagearea-backingstore.
That seems like a really questionable design choice if you ask me. We might have been at a point where IndexDB could be deprecated in favor of a promise based standard, but now one of the most questionable web APIs has another silly reason that it has to exist other than "for legacy applications". The point of an API is not to dictate implementation. This API is almost directly dependent on it's implementation. What happens when the way that x browser stores this information in IndexDB is not exactly the same as y browser? Is the idea to have a js module that works on all browsers? If that was the case why not just release it as a standalone js library? I like the idea of a more modern alternative to localStorage, but this seems like a really bad way to go about it.

@kitsonk
Copy link
Contributor Author

kitsonk commented Mar 13, 2019

What happens when the way that x browser stores this information in IndexDB is not exactly the same as y browser?

Well that is part of the IndexDB spec.

@afinch7
Copy link
Contributor

afinch7 commented Mar 13, 2019

I meant the KV Storage implementations not the browser itself.

@kitsonk
Copy link
Contributor Author

kitsonk commented Mar 13, 2019

I meant the KV Storage implementations not the browser itself.

That is also in the draft spec... Like the ordering of keys, etc. There are a couple concerns regarding this layering though which are also addressed in the draft spec: https://wicg.github.io/kv-storage/#perfect-polyfill

@kitsonk
Copy link
Contributor Author

kitsonk commented Jan 15, 2020

No browsers now intend to implement this, so work is suspended: https://github.com/WICG/kv-storage#status

We shouldn't consider implementing until there is further movement.

@kitsonk kitsonk closed this as completed Jan 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants