Re: [whatwg/storage] Find a better approach to incorporate with other specs; remove export hacks (Issue #153)

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.

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

Message ID: <whatwg/storage/issues/153/1332749905@github.com>