Open ayuishii opened 1 year ago
The way this is worded
A user agent that comes under storage pressure should clear network state and local storage buckets whose mode is "best-effort", ideally prioritizing removal in a manner that least impacts the user.
makes it sound like all storage buckets that are not persistent should be removed when there's storage pressure. But I don't think we want that.
The part that says
ideally prioritizing removal in a manner that least impacts the user.
suggests to me using an algorithm such as, but not limited to, LRU. That is, we should try to avoid removing buckets that are likely to be used again. If the UA does decide to remove a bucket, I don't know how we'd do so in a way that doesn't impact the user.
Thus, I'm not sure I understand the problem. We want to choose buckets carefully, but there's no clear way to dispose of bottles gracefully once one has been chosen.
Unsorted thoughts:
So I think the needed changes are to introduce clearing logic (as needed) and hooks into Storage, and then finish up the integration of IDB and Storage.
Also missing, but requiring changes on the FileAPI spec as well, is describing what happens with Blobs there were retrieved from IndexedDB. I believe at least in Chrome those become invalid after clearing storage, but that is currently not expressible in spec with the hooks FileAPI provides.
When specifying storage bucket removal for Storage Buckets API, we noticed there is no specification for how storage bottles like IndexedDB are removed when faced with storage pressure, or in our case bucket removal. In the Storage spec, under [storage pressure](), it says to clear data "ideally prioritizing removal in a manner that least impacts the user".
In a world with Storage Buckets where we want to encourage developers to have more control over their data management, it seems beneficial to specify how deletion would occur when an IndexedDB bottle is removed. WDYT?
Link to spec issue
@wanderview @evanstade