Re: [IndexedDB] Granting storage quotas

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.


>  2) In Opera, the quota can only be increased in multiples of about 15, so
>> it
>> takes three prompts to get up into the range of gigabytes.
>>
> But there is an unlimited option, yeah?
>

True, but it would be better not to have to give the web app carte blanche.
However, it is a minor point because it is easily fixable.


>  3) The web app can't choose when the question is put to the user.
>> 4) The web app doesn't know how much storage has been allocated, so it
>> doesn't know when a question will be asked.
>> 5) In Opera, if the user chooses "Reject", they don't get prompted again.
>> This means that asking the user at an appropriate time is important for
>> the
>> continued functioning of the web app.  Prompting the user at the wrong
>> time
>> will interrupt them with a page-modal dialog which they might want to get
>> rid of with "Reject", which would potentially break the web app by leaving
>> it unable to get more storage.
>>
> These all feel like user-agent specific worries on how the user agent wants
> to bring this to the attention of the user.
>

It's not user agent specific if the fix involves adding or changing a
programmatic interface, or involves defining behaviour that web apps are
likely to rely on to function correctly.

Regards,
Mark