A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Storage: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 5: Line 5:
* sessionStorage
* sessionStorage
* Indexed DB
* Indexed DB
* Cache API (from service workers, to be clear)
* Filesystem API?
* Filesystem API?
* History API
* History API

Revision as of 17:44, 16 March 2015

Existing APIs

  • Cookies
  • localStorage
  • sessionStorage
  • Indexed DB
  • Cache API (from service workers, to be clear)
  • Filesystem API?
  • History API
  • Notifications API

Storage types

A storage area's scope is that of eTLD+1 or an origin (depending on the implementation). A storage area's mode is either best effort or persistent. A storage area is atomic and includes all the above APIs.

  • Best effort: default on the web, can be upgraded to persistent through the user.
  • Persistent: resources that need to be available in order for the application to run offline and cannot be removed without user consent. (A distinction can be made between app layer (e.g. anything required to play music) and data layer (offline-available music).)

v2 ideas:

  • Temporary: resources that would be useful to cache to reduce latency/bandwidth but are not strictly required when offline. A priority system can be useful so the user agent can determine what to preserve from the temporary storage when running out of the global quota.
  • Named storage areas: making it possible for a single scope to have several storage areas. Other APIs could be used to mark some temporary, attach priorities, etc.



User visits a music application and decides they want to sign up and store 200 music files so they are available offline as the user will travel abroad the next day. It is imperative that these songs cannot be removed without explicit consent from the user.


User plays an RPG for which you need to be online. To improve the user experience the RPG wants to cache as much as possible of the user's current location, nearby locations, and further away locations in game, in decreasing order of priority. So that when the user agent requires space the locations the user is furthest away from will be wiped first. The engine is expected to be stored in persistent storage, though preferable without asking the user.

Photos & video

User wants to store photos taken on a trip abroad without connectivity without losing them. User wants to store photos and always have them available offline for sharing with others.


A social network wants to temporarily cache the latest activities locally.


  • Persistent elastic storage (music, photos, video)
  • Priority-based temporary storage (gaming, social)

Rough plan

Create two modes to back the current set of storage APIs: best effort and persistent. By default the mode for a given eTLD+1 is best effort. After the user opts in it is persistent. Persistent means the user agent does not touch the storage without user consent. It also means that the application gets quite a lot of space. (Ideally most of the hard drive, if that turns into a problem the user will have to delete it...)

v2 ideas: Create a new storage API for explicit priority-based temporary storage. A key/value/priority store, effectively. Application is in charge of determining and changing priorities over time. Or create named storage areas of sorts.

API proposal

partial interface Navigator {
  readonly attribute StorageManager storage;

interface StorageManager {
  readonly attribute StorageMode mode;
  Promise<void> requestPersistent();

  Promise<StorageInfo> getEstimate();

enum StorageMode { "best-effort", "persistent" };

navigator.storage returns a StorageManager.

mode returns the storage mode for the storage scope (eTLD+1 or origin depending on the implementation), with "best-effort" as default.

requestPersistent() changes the storage mode if the user agrees. Fulfills with undefined, rejects with a TypeError if the dialog is dismissed or not acted upon. (Or should it fulfill with StorageMode always?)

getEstimate() returns storage information for the storage scope.


Why no eviction event?

This has been tried on other systems and they always end up with /tmp or some such. When you need space you don't want to ask a dozen applications to clear some before you can start allocating. You want to be able to wipe immediately. That is why priority-based temporary storage is preferable.