WebAPI/Storage2013: Difference between revisions
< WebAPI
Jump to navigation
Jump to search
(Created page with "What we want (some of which we already have) # have explicit temporary and permanent storage * temporary intended to solve caching but cache that can go away without penalty * n...") |
No edit summary |
||
| Line 1: | Line 1: | ||
What we want (some of which we already have) | What we want (some of which we already have) | ||
== have explicit temporary and permanent storage == | |||
* temporary intended to solve caching but cache that can go away without penalty | * temporary intended to solve caching but cache that can go away without penalty | ||
* no permission dialogues! | * no permission dialogues! | ||
| Line 54: | Line 54: | ||
# Priorities | # Priorities | ||
* Simple storage P1 | * Simple storage, P1 | ||
* FileSystem API P2 | * FileSystem API, P2 | ||
* IndexedDB in workers P3 | * IndexedDB in workers, P3 | ||
* Quota API P4 | * Quota API, P4 | ||
* Database migration P5 | * Database migration, P5 | ||
Revision as of 16:25, 25 January 2013
What we want (some of which we already have)
have explicit temporary and permanent storage
- temporary intended to solve caching but cache that can go away without penalty
- no permission dialogues!
- data needs to be deleted if website falls out of use
- we're very close to this, bent about to start reviews
- plug in localStorage to temporary storage
- Honza is working on re-write of localStorage
- appcache rewrite also coming up from Honza
- lower priority
- moving data from temporary to permanent storage (database migration)
- ex. Gmail "go offline"
- ex. Amazon cloud reader
- "simpleStorage" (~async localStorage)
- need very simple API
- high value, low amount of work
- can be built on top of IDB
- Chrome has something already for Chrome extensions
- related things?
- something that uses IDB and/or localStorage?
- general appcache problems
- spec is terrible (poorly written)
- Mounir will help drive spec side of fixing this
- needs input from Jan, Patrick McManus, etc.
- Jonas and Mounir to come up with very rough proposal
- in London, improve proposal and present to others
- Quota API
- similar to what Google has
- that's connected with FileSystem API which means we'll have to just have something similar but not exactly the same
- more predictable than existing 50 MB limit
- "how much am I currently using?" (both permanent and temporary)
- FileSystem API
- like DeviceStorage API?
- sandboxed file system (implemented as a library on top of IDB)
- write a library that uses IDB or falls back to Google's FileSystem API or <something else>
- higher priority than quota API
- do we want to include FileHandle in this API ?
- try to bring in Microsoft views (Apple closer to our view than to Google's)
- IndexedDB in Workers
- Maybe need Workers-As-Service (TM-sicking) support in B2G before this is useful?
- Code should start getting into review queues
- IPC thread needs to be removed in future
- schedule needs to be determined at London work week
- Priorities
- Simple storage, P1
- FileSystem API, P2
- IndexedDB in workers, P3
- Quota API, P4
- Database migration, P5