Re: [IndexedDB] Granting storage quotas

On Apr 21, 2010, at 1:03 PM, Michael Nordman wrote:

> 
> 
> On Wed, Apr 21, 2010 at 12:10 PM, Mike Clement <mikec@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;
> 

Could we create an additional optional parameter for an open request with the type of permanence required? Or is it not a good idea?