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
No edit summary |
|||
Line 1: | Line 1: | ||
== Existing APIs == | == Existing APIs == | ||
* Cookies | |||
* localStorage | * localStorage | ||
* sessionStorage | * sessionStorage | ||
* Indexed DB | * Indexed DB | ||
* | * Filesystem API? | ||
* History API | |||
* Notifications API | |||
== Storage types == | == Storage types == | ||
* Best effort: default | 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. | ||
* 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). | |||
* 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. | * 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. | |||
== Stories == | == Stories == | ||
Line 39: | Line 48: | ||
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...) | 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 == | == API proposal == | ||
Line 64: | Line 73: | ||
<code>getEstimate()</code> returns storage information for the storage scope. | <code>getEstimate()</code> returns storage information for the storage scope. | ||
== FAQ == | == FAQ == |
Revision as of 17:41, 16 March 2015
Existing APIs
- Cookies
- localStorage
- sessionStorage
- Indexed DB
- 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.
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...)
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; }; [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.
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.