W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

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

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Fri, 4 Feb 2011 14:07:31 +0900
Message-ID: <AANLkTim2T0+R4kedEwO+6n_owD_arnm-_kQti4ZYLii7@mail.gmail.com>
To: Charles Pritchard <chuck@visc.us>, Shawn Wilsher <sdwilsh@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, ericu@google.com, Joćo Eiras <joao.eiras@gmail.com>
Cc: public-webapps@w3.org
Thanks for all of your feedbacks.
So it seems like one of the main discussion topic is whether we want to
have "shared quota" between multiple storage mechanisms (per origin,
per persistent/temporary storage class) or not.

On Fri, Feb 4, 2011 at 9:33 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> I think the idea with this spec is that it *requires* that
> implementations share quota between its various storage mechanisms. As
> an implementor I think this is a good idea.

Yes, the primary idea of the proposal is to have a shared quota.
(I should have noted it more explicitly.)

I think and believe that in most cases users or webapps would see
few point in having differentiated quota for different storages,
as long as they all use the same persistent storage (i.e. disk) and
belong to the same origin (=~ same webapp).

As for localStorage, as Charles and Glenn expressed their concerns
it might be better to take it off the table for now.
Or I would simply say we should make it a "temporary-only"
offline storage in the quota terminology, and requesting persistent
quota should have no impact on localStorage quotas.

On Fri, Feb 4, 2011 at 6:56 AM, Glenn Maynard <glenn@zewt.org> wrote:
> One possible approach: rather than having a single implementation of
> StorageInfo, each storage API implements the interface; LocalFileSystem,
> LocalFileSystemSync, IDBDatabase, Storage.  This way, the API doesn't need
> to know how to specify a particular category of each type (storageType goes
> away), and the question of separated quotas is improved.

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.

Thanks,
Kinuko
Received on Friday, 4 February 2011 05:08:22 GMT

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