- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 9 Feb 2011 17:38:28 -0800
- To: Kinuko Yasuda <kinuko@chromium.org>
- Cc: Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@visc.us>, Shawn Wilsher <sdwilsh@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Joao Eiras <joao.eiras@gmail.com>, public-webapps@w3.org, Ian Fette (イアンフェッティ) <ifette@google.com>
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