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

On 2/4/2011 1:30 AM, Jonas Sicking wrote:
> On Thu, Feb 3, 2011 at 5:40 PM, Charles Pritchard<chuck@visc.us>  wrote:
>> The FileSystem API is a tricky thing.
>>
>> indexedDB is more straightforward.
> 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
...
> But I don't see why filesystem should be treated separately? None of
> the above caveats applies to it.

My concern with filesystem is that it's more of an OS-level service
than a UA-level service. Other applications, outside of the UA, may interact
with the files contained on the FS. At some point, I think this would be 
a good thing.
I know that mount points have been brought up before.

I'm just concerned that FS is not yet well defined, whereas idb is 
self-contained.

>> 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?
 From what I recall, Chrome had a 100 meg limit, and Safari did as well.

I was just noting that "unlimited" is not unlimited. It's not relevant 
to the use case.
> 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.
I intended it to address the Quota API we're discussing, not the storage 
mechanism.

> 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.
That's what I think, too: when the user clicks a button.
I don't like seeing a pop-up when I first load the page.

There's about a 5Megs taken-for-granted with localStorage; I wouldn't
mind if another 5 megs without prompt were granted for other services,
bringing the total untrusted space to 10 megs.

Received on Saturday, 5 February 2011 00:57:43 UTC