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: Glenn Maynard <glenn@zewt.org>
Date: Thu, 3 Feb 2011 16:56:23 -0500
Message-ID: <AANLkTinD1yi0Oh+NrXi=St=id6n08Vm2U07u4L-3FFny@mail.gmail.com>
To: Kinuko Yasuda <kinuko@chromium.org>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Thu, Feb 3, 2011 at 5:25 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:

>   interface StorageInfo {
>    // storage type
>     const unsigned short TEMPORARY = 0;
>     const unsigned short PERSISTENT = 1;
>
>     // To query how much storage is available and currently in use.
>     void queryUsage(unsigned short storageType,
>                     UsageCallback usageCallback);
>
>    // To request a new quota size.
>     void requestQuota(unsigned short storageType,
>                       unsigned long long newOriginQuotaInBytes,
>                       QuotaCallback quotaCallback);
>   };
>


> With this API I assume multiple offline storage APIs share the same
> single (persistent) quota and usage info per origin, but that detail
> could be probably left up to UA.
>

It'd be good to be able to request quota with a consistent interface, rather
than each API having its own interface, which seems to be what's starting to
happen for example with LocalFileSystem.

What happens if the UA doesn't share quotas between different APIs?
Requesting 250 MB of storage would actually be granting much more; for
example, 250 MB for IndexedDB and 250 MB for localStorage.  (Tracking quotas
separately seems very likely, especially with filesystem APIs.)

What happens if the practical limits for an API differ?  For example,
filesystems can hold as much storage there is disk space, but localStorage
may have much lower reasonable limits.  UAs may want to impose a quota cap
that differs between storage APIs.  If code requests 4 GB of storage in
order to store assets with the filesystem API, there's no way for this API
to differentiate between the two--allowing the 4 GB for filesystem or
IndexedDB but not for localStorage.

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.

Note, though, that requesting quota for multiple APIs in this way should
*not* result in the UA prompting the user multiple times.  If requests are
made to multiple APIs in quick succession (eg. before the script returns to
the browser), it should coalesce them and only ask the user once for the
total.  Prompting the user two or more for quota permissions ("Allow 100 MB
for IndexedDB?" "Allow 500 MB for filesystem access?") would be a major UI
failure.


On Thu, Feb 3, 2011 at 7:32 AM, João Eiras <joao.eiras@gmail.com> wrote:
> General note: using bytes as measure is probably overkill. While I
> doubt localStorage would even exceed a couple megabytes, making an
> entire e-mail account available offline with indexedDb or web sql db
> could easily climb to a couple GBs. Perhaps kilobytes is better ?

Saying 4*1024*1024*1024 isn't a lot of work, and using different units means
I have to remember which units each function uses.

-- 
Glenn Maynard
Received on Thursday, 3 February 2011 21:56:58 GMT

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