Re: [whatwg/storage] Bucket hooks (#18)

FWIW, I have the feeling I'm missing a simpler solution here and as you can tell this is very much a sketch. Would love to hear your thoughts.

The idea here is to define existing storage APIs, such as service workers and localStorage, on top of these primitives so we get a well-defined Clear-Site-Data and hopefully some other benefits too. I suspect this architecture might also work for the Storage Access API in due course, though it depends a bit on how all that will pan out.

Storage APIs (e.g., localStorage) need to define:

* A **storage identifier** (a string), e.g., "localStorage". (These should match those of UsageDetails from https://github.com/whatwg/storage/pull/69/files.)
* A **replace algorithm** to abort transactions or some such in the event of storage bucket replacement. (Could be nothing if there's no cleanup to be done.)
* They need to invoke the "obtain a storage bucket area map" algorithm (outlined below) for environments that end up using the API and use the returned map as the place to store all their data.

The Storage Standard needs to define:

A registry of all storage identifiers and an easy way to get from one to its corresponding replace algorithm.

A **storage bucket** holds a **map** of storage identifiers to storage areas.

A **storage area** is a struct consisting of **map** and a **proxy map pointer set**.

(The idea is that storage area's map holds the actual storage. It's in a map because those are easy to work with. How the map is persisted is implementation-defined. How to make it available across process boundaries is implementation-defined.)

A **proxy map** has identical operations to a map and performs those on its **underlying map**.

(We hand out a proxy map to a storage API so we can replace the actual map behind the scenes.)

New algorithms:

To **obtain a storage bucket area map**, given a storage identifier _identifier_ and an environment _environment_, run these steps:

1. Let _key_ be the result of obtaining a storage key from _environment_. (This should be less hand-wavy.)
1. Let _bucket_ be the storage bucket for _key_. (This should be less hand-wavy.)
1. Let _storageArea_ be _bucket_'s map[_identifier_].
1. Let _proxyMap_ be a new proxy map.
1. Append a pointer to _proxyMap_ to _storageArea_'s proxy map pointer set.
1. Set _proxyMap_'s underlying map to _storageArea_'s map.
1. Return _proxyMap_.

(The above algorithm is intended for storage APIs. They would invoke this upon initialization to get a map to store things in.)

To **replace** a storage bucket _old_ with a storage bucket _new_, run these steps:

1. Atomically:
   1. Replace _old_ with _new_. (This should be less hand-wavy and probably talk about the site storage unit.)
   1. For each _identifier_ → _storageArea_ of _old_'s map:
      1. For each _proxyMapPointer_ of _storageArea_'s proxy map pointer set:
         1. Let _newStorageArea_ be _new_'s map[_identifier_].
         1. Set the value of _proxyMapPointer_'s underlying map to _newStorageArea_'s map.
         1. Append _proxyMapPointer_ to _newStorageArea_'s **proxy map pointer set**.
1. For each impacted agent of ...: (This should be less hand-wavy)
   1. Queue a task to:
      1. For each _identifier_ of ...:
         1. Run _identifier_'s corresponding replace algorithm with ....

(There's a couple things that need to be filled out here including what kind of details the replace algorithm might need to clean up the relevant APIs.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/18#issuecomment-614751336