search

WICG / shared-storage

Explainer for proposed web platform Shared Storage API
Other
88 stars 21 forks source link

per-entry retention with 'touch' to extend expiration date #45

Closed zhengweiwithoutthei closed 1 year ago

zhengweiwithoutthei commented 1 year ago

The retention policy in the explainer mentioned that data will be cleared after 30 days after creation, on a per-origin basis. This is not ideal for use cases that needs a persistent storage for longer than 30 days. I would suggest two changes:

1) Instead of per-origin retention, we should make the retention per-entry or per-key. Each origin can store many key/values for different use cases. Those key/value can be written at different time and accessed at different cadences. It doesn't make sense to make all entries to share the same retention as the very first entry which created the database. Imagine that you want to write a new entry to a database of an origin that was created 29 days ago. Even knowing that this new entry has only 1-day lifetime (you can learn it from the worklet), there is no way to extend the databased's expiration date.

2) 'touch' an existing entry with set(, { ignoreIfPresent: true }) (maybe even with sharedStorage.get()) should extend the expiration date of that entry for another 30 days. This will make sure we only clear the entries that are not actively accessed.

SpaceGnome commented 1 year ago

See also https://github.com/WICG/shared-storage/issues/46

jkarlin commented 1 year ago

Anothe reason the existing per-database expiration is awkward for developers is that if you write a new key on day 29, then it'll be deleted the next day. The per-key suggestion is much more deterministic in that it will last for at least 30 days.

I think overall these suggestions make sense. It's also similar to how FLEDGE works (per-key expiration that gets reset on write).