- From: Charles Pritchard <chuck@visc.us>
- Date: Fri, 04 Feb 2011 16:57:10 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Shawn Wilsher <sdwilsh@mozilla.com>, Joćo Eiras <joao.eiras@gmail.com>, public-webapps@w3.org
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