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

I'm not sure FileSystem is necessarily any trickier from a user's
perspective -- it's all storage that is taking up space on my HD (at least,
for now the filesystem is just a directory under the user's profile in
Chrome). I think it fits fine in the unified quota model. (And FWIW we are
looking at replacing the SQLite backend for Indexed DB in Chrome, so it's
not generally safe to make such assumptions about how implementations
currently work remaining the same as you have below ;-) Still though, as an
end user or developer using the API, I really shouldn't have to care about
such details.)

As for our plans in Chrome, currently we are planning to give 5GB quota when
the site asks for persistent storage space, provided the site has asked for
between 0 and 5GB (there will be a user prompt that simply states "X wants
to store data on your computer permanently". If the site asks for more than
5GB we will show a prompt "X wants to store a large amount of data on your
computer permanently" and grant that amount, both cases after user consent.
Still something of an open question as to what happens when a site hits the
limit, whether we go the FF model or try something else. It's not clear to
me that we actually have to prompt the user, or whether we can make
inferences from user actions. 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. I suspect most user's probably won't care,
except perhaps on constrained (mobile) devices.

I think there is a lot of room for innovation beyond just "ask the user" :)

-Ian

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.
>
> 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).
>
>
> -Charles
>
>
> On 2/3/2011 5:08 PM, Shawn Wilsher wrote:
>
>> On 2/3/2011 4:35 PM, João Eiras wrote:
>>
>>> Or adding unnecessary complication to the implementation.
>>>
>> I'm not looking to make my job easier (as an implementer); I'm looking to
>> make it easy to use.  At least with IndexedDB, we generally choose the
>> option that is easier for the consumer as long as it isn't extremely
>> difficult to implement (which I do not see this being the case for quotas).
>>
>> Cheers,
>>
>> Shawn
>>
>>
>
>