On 2/4/2011 1:30 AM, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 5:40 PM, Charles Pritchard<ch...@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.
