Re: [IndexedDB] Granting storage quotas

On Thu, Apr 22, 2010 at 3:14 PM, Dumitru Daniliuc <dumi@chromium.org> wrote:

> fwiw, i agree with michael and tab that we should split all storage into
> "permanent/persistent" and "temporary/evictable/purgeable". however, i don't
> think we need separate calls such as openDatabase() and
> openPermanentDatabase(). i think we should just add an optional isPersistent
> parameter to openDatabase() which would default to 'false'.
>
>
> On Wed, Apr 21, 2010 at 2:27 AM, Mark Seaborn <mseaborn@chromium.org>wrote:
>
>> On Tue, Apr 20, 2010 at 7:17 PM, Shawn Wilsher <sdwilsh@mozilla.com>wrote:
>>
>>> On 4/20/2010 4:11 AM, Mark Seaborn wrote:
>>>
>>>> 1) It doesn't allow a web app to ask for a storage allocation up front,
>>>> before it starts to consume the storage.
>>>>
>>> Why does that matter?
>>>
>>
>> It doesn't support the use cases that I suggested at the start of the
>> thread:
>>
>
>>
>> "* An e-mail web app requests an amount of storage that is large enough to
>> store all your current e-mail, plus your e-mail for the next year at
>> projected rates.  As this runs out, it can request more.
>> * A backup web app requests an amount that is large enough to store your
>> data."
>>
>> Suppose I leave an e-mail web app running on my laptop while I'm not using
>> it, expecting it to sync my mail.  Then I take the laptop somewhere where
>> there's no network connectivity.  I don't want to find that the e-mail app
>> failed to fetch my e-mail because it ran out of storage and was stuck while
>> the browser displayed a prompt that I wasn't there to see.
>>
>> The same goes for the backup example.  I wouldn't want to find that the
>> backup app has failed to back up my data because it got stuck at a prompt.
>> This wouldn't happen if the backup app had the ability to request, up front,
>> the amount of storage that it knows it will need.  This request might happen
>> at the point where the user specifies what files they want the app to copy.
>>
>
> how about adding a simple async API that would allow apps to request
> (permanent) storage up front?
>
> window.getPermSpace(desiredPermSpace, permSpaceGrantedCallback);
>
> function permSpaceGrantedCallback(permSpaceQuota, permSpaceUsed) {
>   // store stuff
> }
>
> the apps could use this API to:
> 1. request enough space before doing anything -- no quota-related failures
> in the middle of a storage operation (unless the hard drive unexpectedly
> fills up, the user loses the network connection, etc.)
> 2. figure out what to store on the user's machine (number of emails to
> sync, etc.) based on how much permanent space they got and how much of it
> they're already using.
> 3. figure out the amount of space they are using/can still use at any point
> in time (and potentially run a clean up job when they're getting close to
> their quota, etc.).
>
> the UAs could use this API to:
> 1. asynchronously get user's input when needed.
> 2. cleanly delete any permanent data stored by an app before the app starts
> using that data, if the user decides not to give any permanent storage to
> that app.
> 3. do better perm space book-keeping and prevent potential abuses before
> they happen.
>
> and future storage APIs (sync or async) wouldn't have to worry at all about
> managing quotas.
>

There are a few details I might tweak, but overall I would be happy with an
approach like this.  In Chromium, we would probably give 0 permanent storage
by default (all evictable/volatile/etc) and make apps request it like this.
 In Chromium, there are other ways to request more storage (for example, in
the manifest of Chrome extensions) so this would even fit in seamlessly with
them (since they could request and we'd always say "sure!").

I know that we've resisted baking explicit quotas into the web platform
before, but the feedback we've gotten from virtually every developer on this
is negative.  I think this is a good compromise to say that platforms which
absolutely don't want to bake in the concept of quotas can only offer
evictable/volatile storage.  And I like that requesting permission is
detached from opening any specific database/file.  This means that we can
add other methods of requesting quota fairly easily as devices evolve.

J