- From: Charles Pritchard <chuck@visc.us>
- Date: Thu, 03 Feb 2011 17:40:50 -0800
- To: Shawn Wilsher <sdwilsh@mozilla.com>
- CC: Joćo Eiras <joao.eiras@gmail.com>, public-webapps@w3.org
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 >
Received on Friday, 4 February 2011 01:41:21 UTC