- From: Andrew Sutherland <notifications@github.com>
- Date: Mon, 18 May 2020 17:19:09 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/pull/334/c630501819@github.com>
> * _name_ → (_queue_, _database_) I like this one because: - Having the key be the name seems like a big win over the compound key approach of `("queue", name)`. - Separating the queue from the database seems like a nice separation of concerns, especially since the database is something that definitely involves touching disk and is conceptually subject to corruption. Whereas the connection queue is strictly a runtime concept. ### Blobs / Files A related question is how IndexedDB-minted Blobs and Files will handle the replace operation and whether this impacts the map. Gecko definitely invalidates IndexedDB-minted Blobs and Files when Clear-Site-Data and privacy data-clearing operations occur. From other discussions in the past I have the impression this is also the case in Blink. The File API Spec doesn't really get into this in [the section on deserialization and the get stream algorithm](https://w3c.github.io/FileAPI/#blob-section) which implies a simplified model where no effort is made to de-duplicate Blob contents or store them to disk, but does leave implementation a broad latitude to [throw errors](https://w3c.github.io/FileAPI/#dfn-error-codes) when get stream is invoked to compensate for the underlying realities. It seems like we might want to formalize the realities of Blobs/Files now since Clear-Site-Data makes this previous edge-case something content can explicitly trigger instead of a user-initiated edge-case, plus multiple storage buckets presumably would also want to be able to dispose of the underlying blobs and their quota usage in a deterministic fashion. Doing this might involve a hook where [get stream](https://w3c.github.io/FileAPI/#blob-get-stream) could end up needing to involve some part of the storage hierarchy, in which case it's possible the map might need to store additional data to support this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/pull/334#issuecomment-630501819
Received on Tuesday, 19 May 2020 00:19:22 UTC