1276576 - Remove support for temporary storage (aka shared pool)

Status: NEW

(Core :: Storage: IndexedDB, task, P3)

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

There doesn't seem to have been any cross-vendor discussion, and AFAIK no other vendor has expressed interest. We should remove this feature or get it specified.

Comment 1

[Andrew Overholt [:overholt]]

Jan and Anne, are the use cases here taken care of by the Storage API? Do we have any users of this?

Comment 2

[Anne (:annevk)]

Storage doesn't have "temporary", just "best-effort" and "persistent", but I don't think we want the design we have today if we introduced something like this in the future. (In particular, as I understand it the low-level design today puts temporary in its own folder, rather than metadata annotations. Furthermore, the API we have today is not going to stand the test of time.)

Comment 3

[Jan Varga [:janv]]

Explicit temporary storage was useful before we had "default" storage which is based on temporary storage but specific origins are treated as persistent and yes it's a separate folder.
Anyway, explicit temporary storage is currently used by asmjs caching, so we shouldn't remove it entirely. IndexedDB would just refuse indexedDB.open(dbName, { storage: "temporary" }
Now when I think about it ... I remember we wanted to create a separate repository/folder for asmjs caching, so in the end we can just stop exposing temporary storage to IndexedDB and use it by asmjs internally with the option to modify it for asmjs needs in the future.

Removal of IndexedDB databases stored in temporary storage should be easy after bug 1195930 which introduces more robust internal <profile>/storage versioning/upgrading.

Also note that removal of { storage: "temporary" } is not enough for bug 1275496. There's also { storage: "persistent" } - so called explicit persistent storage.

Comment 4

[Luke Wagner [:luke]]

FWIW, for WebAssembly, we're making caching explicit by making a compiled (but not yet instantiated) module structured-cloneable:
  https://github.com/WebAssembly/design/blob/master/JS.md#structured-clone-of-a-webassemblymodule
Which means that wasm won't need any of the custom integration with QM that asm.js has; it'll just go into the IDBObjectStore.  I'd rather not remove dom/asmjscache before wasm has shipped, but I'm happy to some time after that.