Specifying "indexedDB" storage bottle deletion when data is evicted by quota

w3c / IndexedDB

Indexed Database API

https://w3c.github.io/IndexedDB/

Other

240 stars 62 forks source link

Specifying "indexedDB" storage bottle deletion when data is evicted by quota #400

Open ayuishii opened 1 year ago

ayuishii commented 1 year ago

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

evanstade commented 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.

inexorabletash commented 1 year ago

Unsorted thoughts:

Beyond quota, other cases to consider are when a user clears storage, or when Clear-Site-Data is served. I think that's what @evanstade is alluding two - there's what to remove, and then the mechanics of removing it.
https://github.com/w3c/IndexedDB/pull/334 is an attempt to define IDB as a storage endpoint, which I think would be a prerequisite for getting everything specified accurately.
IDB spec has: "A connection may be closed by a user agent in exceptional circumstances, for example ... clearing of the storage key's storage." (see https://w3c.github.io/IndexedDB/#database-connection). If we introduce the notion of clearing a bucket to Storage, this would be where we'd want to hook it up.

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.

mkruisselbrink commented 1 year ago

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.