Find a better approach to incorporate with other specs; remove export hacks

[saschanaz]

It seems multiple specs are using the storage model terms without actual export.

• Service Worker: https://github.com/w3c/ServiceWorker/blob/5eb478f8875ae3b3fa0eb1dc4e7e527675617fd1/docs/index.bs#L118
• IndexedDB: https://github.com/w3c/IndexedDB/blob/91f866a7b6b9799c9fcf9584a4a870b4e534a9c6/index.bs#L68

Now that w3c/web-locks#75 is also adding references, we should really export them (maybe find a better way to expose the model as suggested in comments) and remove those hacks. (Also filed speced/bikeshed#2410 to prevent this.)

[inexorabletash]

Maybe implicit, but: alternately, work with the editors of those specs (hey, that's me and @saschanaz) to find a better approach, which may involve changes on both sides.

I talked about this briefly with @annevk at TPAC earlier this year at a high level; it really just needs some proposals made and discussed. I hope to have more time for this in 2023 than I've had for the last year.

[inexorabletash]

Oh, and I'm not saying to wait for me to do it. Please anyone, suggestions welcome!!!

[annevk]

Right, I think the model as-is doesn't work for certain use cases and this wasn't flagged when the model was designed. As such we need to make changes to better account for what SW, IDB, and WL need.

I suspect it's not as simple as exporting the terms unfortunately.

[inexorabletash]

Initial stream-of-consciousness thoughts:

My impression is that the current design of bottles and the proxy map is that they match the needs of Local Storage, where:

1. The actual backing store operates on another thread/process
2. The backing store can be described as a key/value mapping
3. Access to the backing store has no additional coordination or sequencing beyond get/set/clear/enumerate/clone

While the first should be true for all storage endpoints, for some endpoints describing their operation in terms of the second and third requires significant contortions that would make the specs difficult to understand.

• Web Locks could be thought of as a mapping from the lock name to a manager object that handles requests. But the API is not used from script as e.g. var manager = proxy_map.get("name"); manager.requestLock(...); And if it was, the operations of the manager object could not be described through the proxy map concept.
• IndexedDB could similarly be thought of as a mapping from database name to some manager for connections, but that doesn't match how it is specified and how connections are granted and what is done with them (e.g. the eventual transactions and get/set operations) can't (easily?) be described via the proxy map.
• I haven't thought as much about Cache Storage; while at a high level the endpoint is a map (name to cache), the async nature of each operation and operations on caches as a whole vs. operations within caches seem to imply sequencing that goes beyond what the proxy map provides.

At least for Web Locks and Indexed DB, one idea is that it would be easier to specify if the "thing in the bucket" for a storage endpoint doesn't need to be a bottle, but could be defined by the endpoint. And we still need a way to obtain a proxy, but that would be more abstract rather than a map. But we should require that all operations between the proxy and the endpoint need to be "in parallel".

At the risk of over-specifying, I could imagine describing IndexedDB's "thing in the bucket" as a connection factory and the IDBFactory as holding a proxy; then the IDBDatabase (a database connection) and IDBTransaction (a transaction) route everything through that proxy - e.g. store.put(value, key) turns into proxy.request(dbname, transactionid, storename, PutOp, key, value). The spec could abstract some of that away with proxy wrappers for the connection and transaction. This ends up looking a lot like the implementation in Chrome, at least.

Again, just initial thoughts to get the conversation going.

[annevk]

cc @whatwg/storage