W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Granting storage quotas

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 23 Apr 2010 17:11:17 +0100
Message-ID: <u2y5dd9e5c51004230911yd0a39e88sb370670226068fb0@mail.gmail.com>
To: Nikunj Mehta <nikunj@o-micron.com>
Cc: Michael Nordman <michaeln@google.com>, Mike Clement <mikec@google.com>, public-webapps@w3.org
On Fri, Apr 23, 2010 at 3:39 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:

>
>
> 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?
>

I think this is what Dumi suggested.  The only hitch is that both IndexedDB
and WebSQLDatabase's open commands already take optional parameters, so it'd
start to get kind of ugly.  (Presumably, you'd have to add undefineds in for
any optional param you want to accept the default for.)  But I don't
necessarily think that problem is a show stopper.
Received on Friday, 23 April 2010 16:12:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT