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: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 4 Feb 2011 01:30:52 -0800
Message-ID: <AANLkTi=K+9zxa3JN1CcMKkJQzLSkaPJ313KFZz5K3rYE@mail.gmail.com>
To: Charles Pritchard <chuck@visc.us>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, Joćo Eiras <joao.eiras@gmail.com>, public-webapps@w3.org
On Thu, Feb 3, 2011 at 5:40 PM, Charles Pritchard <chuck@visc.us> wrote:
> I rather like the prompt in the new FF builds; it's similar to the prompt on
> Mobile Safari;
> when you get into the site, it asks you if you're ok storing data, and it
> allows you to specify a quota stepping.
> FF does a great job on applicationCache + quota in that area.
> The FileSystem API is a tricky thing.
> indexedDB is more straightforward.
> Let's take localStorage off the table for quota control: it's set at 5 megs
> in practice,
> and it's a very different storage mechanism.
> In practice, websql, appCache and indexeddb are backed by the public domain
> sqlite library
> and they share a quota on implementations.
> I'd like to discuss FileSystem permissions as a distinct item,
> as localStorage is distinct.

I'd be fine with exempting localStorage from API and just lock it at
5MB. It's tricky anyway since it's a synchronous API. Further, the
current limits are not defined in terms of size-on-disk but rather
size-of-data. Additionally, at least firefox grants 5MB of storage to
localStorage without prompting. The same is not true for any of the
other storage APIs that we support, and likely won't be for any future
ones we'll support.

But I don't see why filesystem should be treated separately? None of
the above caveats applies to it.

> Use case for the quota API:
> When a user wants to download a large set of data for offline use,
> Scripting needs permission "unlimited" space.
> "unlimited" is often set at 100 megs.
> The user has to stick around until their quota is full,
> if they've set a low quota amount.
> Scripting should not have to require "100 megs" explicitly
> when a user first lands on a page.
> The user should only see an increase quota request
> following an input action (such as clicking a link or button).

You're setting a lot of, to me seemingly arbitrary, restrictions here.
Why does "unlimited" equal 100 MB? Why shouldn't the page request
quota up front? Why shouldn't the page be allowed to request quota any
time it chooses?

I also don't see why the scenario is specific to the FileSystem API.
The same thing can happen with IndexedDB. Consider for example a
webmail application which wants to download a large amount of emails
and store locally for offline access.

The solution here is for the page to estimate how much space it needs
and then request that up front. Be that when the user clicks a "sync
now" button, or as soon as the user arrives at the page. Whatever the
page thinks produces the best UI. The user can immediately make a
choice to grant the quota and then the page can take its time to
download the data. This seems to work as well for filesystem as for
indexedDB and app-cache.

/ Jonas
Received on Friday, 4 February 2011 10:34:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC