Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)

2011/2/7 Kinuko Yasuda <kinuko@chromium.org>:
> On Sat, Feb 5, 2011 at 7:29 AM, Glenn Maynard <glenn@zewt.org> wrote:
>> On Fri, Feb 4, 2011 at 12:07 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:
>>>
>>> If we want to make the quota API treat each API differently this would
>>> make a lot sense, but I'm not fully convinced by the idea.
>>> Putting aside the localStorage for now, do you still see significant
>>> issues in having a sshared single quota?  Also let me note that
>>> this API does not and should not guarantee that the app can actually
>>> *write* that amount of data into the storage, even after the quota is
>>> granted, and the UA could still stop an API to write further even if
>>> it's within the quota.
>>
>> I suppose that even the 2-3x difference--requesting 256 MB and actually
>> getting 512 MB over different APIs--is acceptable, since to users,
>> requesting storage is an order-of-magnitude question more than a precise
>> number.  As long as implementations are still allowed to implement separate
>> quotas if they want, it's probably acceptable for this API to not reflect
>> them precisely and to be biased towards a shared quota.
>
> If we think that most of users/developers wouldn't be interested in
> specifying 'giving X bytes to storage A' and 'giving Y bytes to
> storage B' or such that while both storage A and B eats the user's
> disk, then probably UA should evolve in that direction.  That's my
> assumption and why the proposed API look like that (i.e. biased
> towards a shared quota).

Agreed.  Users won't care about the distinction, so let's make it so
developers don't have to care.

>> 2011/2/4 Ian Fette (イアンフェッティ) <ifette@google.com>
>>> For instance, if a user has been using a site for months, uses it
>>> frequently, and the site hits its 5GB limit but there's still 300GB free on
>>> the drive, perhaps we just give the site another 5GB and give the user a
>>> passive indication that we've done so, and let them do something if they
>>> actually care.
>>
>> That's interesting; reducing the amount users are nagged about things that
>> they probably don't care about is important.  It would also need to suppress
>> prompting from calls to requestQuota if the quota increase would have been
>> allowed automatically.
>
> The proposing API itself doesn't specify the frequency of
> notifications or the behavior of out-of-quota scenarios, but probably
> it might be worth adding some note about calling 'requestQuota()' does
> not (and should not) always need to result in the UA prompting, and it
> must be generally prohibited prompting the user too frequently.

Possibly in non-normative text, but I think it's implied if you just
leave it out that implementers can do whatever they want with the UI.

> The bottom line of whether we should prompt or not is, I suppose, if
> UA ask for the user's permission to store some data in the storage,
> the UA shouldn't delete the data without the user's permission.

Yup.

Received on Thursday, 10 February 2011 01:39:15 UTC