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

Re: [IndexedDB] Granting storage quotas

From: Dumitru Daniliuc <dumi@chromium.org>
Date: Thu, 22 Apr 2010 15:14:27 -0700
Message-ID: <y2te753f47f1004221514m743591a5m5976671183a2554c@mail.gmail.com>
To: Mark Seaborn <mseaborn@chromium.org>
Cc: public-webapps@w3.org
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.

thanks,
dumi
Received on Thursday, 22 April 2010 22:14:58 GMT

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