Storage

Existing APIs

• localStorage
• sessionStorage
• Indexed DB
• Cookies

Storage types

• Best effort: default for non-temporary APIs, can be upgraded to persistent through the user.
• Persistent: resources that need to be available in order for the application to run offline. A distinction can be made between app layer (e.g. anything required to play music) and data layer (offline-available music).
• 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.

Stories

Music

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.

Games

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.

Social

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

Requirements

• 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...)

Also 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.

API proposal

partial interface Navigator {
  readonly attribute StorageManager storage;
};

[Exposed=(Window,Worker)]
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.

v2: Explicit temporary storage API (does not affect the best-effort/persistent area), or perhaps named storage areas (divide up a storage scope).

FAQ

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.