On Wed, Apr 21, 2010 at 12:10 PM, Mike Clement <mi...@google.com> wrote:
> FWIW, the "transient" vs. "permanent" storage support is exactly why I > eagerly await an implementation of EricU's Filesystem API. Being able to > guarantee that the UA will not discard potentially irreplaceable data is of > paramount importance to web apps that want to work in an offline mode. > > I also find that the current arbitrary quota limit of 5MB per domain makes > local storage APIs unusable for all but the most rudimentary apps (e.g., > sticky note demo apps). There is an asymmetric distribution of local > storage needs out there that no one is yet addressing (e.g., a photo- or > video-related app might need GBs of local storage, an offline mail app might > need tens or hundreds of MB, a TODO list app might only need kilobytes, > etc.). > I wholeheartedly support any effort to coordinate quota management among all > of the various local storage APIs. The issue of quota limits is something > that browser vendors will need to address soon enough, and it's probably > best left up to them. The need for "permanent" storage across all local > storage APIs, though, is something that in my opinion should come out of the > standardization process. > Here's a stab at defining programming interfaces that make a distinction between "transient" vs "permanent" for the storage mechanisms. If we make additions like this, we should use the same terminology across the board. // WebSqlDBs, also could work for IndexedDBs window.openDatabase(...); // temporary window.openPermanentDatabase(...); // AppCaches, embellish the first line of the manifest file CACHE MANIFEST CACHE MANIFEST PERMANENT // FileSystem, see the draft, i've change the terms a little here window.requestFilesystem(...); // evictable window.requestPermanentFilesystem(...) // LocalStorage window.localStorage; // purgeable window.permanentLocalStorage;