Replacement design

[Anne van Kesteren]

Replacing needs to happen at the level of storage units (or shelves) and potentially across the user agent's storage map and the browsing session's storage map.

This means that potentially many storage buckets end up being replaced. For now only the "default" storage buckets would be impacted, but in the future others would as well.

One question here is around the expectations of the "bucket API" and Clear-Site-Data or navigator.storage.clear(). Would the non-"default" buckets be expected to be "gone" or only be emptied?

Another question is around the storage access API. With that you might get access to a different storage unit, but the buckets would potentially also mismatch. Perhaps that's a good reason to not allow third parties without storage access to create buckets?

cc @hober @asutherland @pwnall @inexorabletash

[Joshua Bell]

cc: @mkruisselbrink too.

My expectation would be "gone", not emptied, if there's an observable difference. I assume a "bucket API" would allow enumeration of buckets and/or inspecting bucket properties, and therefore the presence of buckets would serve as a form of storage itself and should be cleared.

I don't think we have a coherent theory around storage access/3P storage yet, but: disallowing SGTM.

[Marijn Kruisselbrink]

I agree with everything @inexorabletash said.

[Joshua Bell]

Adding on: for Clear-Site-Data and "buckets API" (and maybe navigator.storage.clear()) there should be a way to clear particular buckets, including the default bucket, separate from the rest. But the default should be a full reset.

[Anne van Kesteren]

Note to self: #18 (comment).

[Anne van Kesteren]

Modest progress:

---

To replace a storage shelf, given a storage shed shed, storage key key, and a storage shelf newShelf, run these steps:

1. Let oldShelf be shed[key].
2. For each identifier → bottle of oldShelf's bucket map["default"]:
   1. Let newBottle be newShelf's bucket map["default"][identifier].
   2. For each proxyMapReference of bottle's proxy map reference set:
      1. Set the value of proxyMapReference's underlying map to newBottle's map.
      2. Append proxyMapReference to newBottle's proxy map reference set.
   3. Run the replace a bottle algorithm of the registered storage endpoint whose identifier is _identifier with TODO.
3. Set shed[key] to newShelf.
4. Discard oldShelf.

---

This would mean that we'd run an algorithm for each impacted bottle once, in the "storage process". That algorithm would be up to the storage endpoints to define and would have to queue tasks and such as needed. For localStorage and sessionStorage the algorithm would no-op.

I think this would work for service workers looking at w3c/ServiceWorker#1506.

I was thinking that we'd not pass this algorithm a storage key, but perhaps the old and new storage bottle is not enough for some reason?

[Andrew Sutherland]

This would mean that we'd run an algorithm for each impacted bottle once, in the "storage process".

I'm trying to reconcile this with the algorithm being run inside the "For each proxyMapReference of bottle's proxy map reference set:" loop and am confused. Does this imply every set will have exactly one proxy map reference?

[Anne van Kesteren]

Sorry, it was meant to only run once per bottle. I've updated my comment.