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

Split the cache API into its own spec #879

Open
jakearchibald opened this issue Apr 12, 2016 · 5 comments
Open

Split the cache API into its own spec #879

jakearchibald opened this issue Apr 12, 2016 · 5 comments
Assignees
Milestone

Comments

@jakearchibald
Copy link
Contributor

They're separate, so should be separate

@jakearchibald jakearchibald added this to the Version 1 milestone Apr 12, 2016
@jakearchibald
Copy link
Contributor Author

F2F: group agrees

@jakearchibald jakearchibald self-assigned this Apr 12, 2016
@jakearchibald
Copy link
Contributor Author

F2F: decide on this before v1, but leaning towards yes. I'll do the work when I have time.

@jakearchibald
Copy link
Contributor Author

Pre F2F notes: Do we still want this for V1? Where should the new spec live? WICG?

@jakearchibald
Copy link
Contributor Author

F2F:

  • This isn't high priority
  • We should do this when we're making significant changes, eg the transactions stuff

@aerik
Copy link

aerik commented Mar 31, 2022

This issue is nearly 6 years old. Can we please not wait any longer, and, when splitting it into it's own spec, can we also resolve #165 which I just posted? Splitting the cache API into it's own spec makes sense conceptually, and doing this and making it not require secure contexts will make it consistent with IndexedDB, which is functionally resembles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants