<div class="gmail_quote">2010/3/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <span dir="ltr"><<a href="mailto:ifette@google.com">ifette@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

As I talk with more application developers (both within Google and at large), one thing that consistently gets pointed out to me as a problem is the notion of the opaqueness of storage quotas in all of the new storage mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the Filesystem API being worked on in DAP, etc). First, without being able to know how large your quota currently is and how much headroom you are using, it is very difficult to plan in an efficient manner. For instance, if you are trying to sync email, I think it is reasonable to ask "how much space do I have," as opposed to just getting halfway through an update and finding out that you hit your quota, rolling back the transaction, trying again with a smaller subset, realizing you still hit your quota, etc. <div>


<br></div><div>I would like to see a method added, for any "storage mechanism", something like "GetCurrentQuota()" and "GetCurrentQuotaUsed()". (I specifically don't care what they're called or the details, e.g. whether they need to be callbacks, I just want to see us address this use case.)</div>

</blockquote><div><br></div><div>I too have heard this plea over and over again.  I've also heard that even knowing the order of magnitude of headway would be useful.  This is nearly a deal breaker for a lot of apps.  Having to gracefully handle a quota related error _every_ single time you do an operation is a big pain.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Secondly, I think we need a better answer for obtaining a larger quota. Let's think for a moment about the use cases -- in most instances, I am going to make a decision that I want to use an application offline. (I personally would not expect to browse to a site and then just happen to be able to use it offline, nor do I expect users to have that expectation or experience. Rather, I expect going through some sort of flow like clicking something that says "Yes, I want to use Application X offline". At this point, I want to get any permissioning issues out of the way. I don't want to wait until the data sync to the Web XXX Database starts failing 10 minutes later to pop up an infobar that is no longer in the user's current flow / state of mind, I don't want to then pop up another infobar 30 minutes later saying their Filesystem quota is full, etc. I want to be able to get this out of the way all at once, at a point in time where I believe the user is actually in the mindset / task of deciding that they want to use my web application. I specifically do not want to have to deal with 4 different infobars, potentially at 4 different points in time, to use an application I have decided I want to use.</div>


<div><br></div><div>To that point, I would like to see a method added (presumably that can only be called in response to a user action) that would allow my page to request a bundle of permissions. I am going to go out on a limb here and include geolocation in this bundle. Some sort of a callback type API where I pass in a list of permissions that I want, the UA is free to display this to the user in whatever mechanism it determines appropriate (if at all -- e.g. if the user has already denied geolocation and that's being requested again, as a UA i might decide not to present that request). That is, I could pass in something like ["LocalStorageQuota", 20*1024*1024 /* 20M */, "WebSQLQuota", 1*1024*1024*1024 /* 1GB */, "FileSystemQuota", 10*1024*1024*1024 /* 10GB */, "Geolocation", true], and the callback could then (as a convenience) indicate the current quota for all of the things that I asked for, so that I could figure out whether the user accepted, denied, or accepted and modified the request and how I can then proceed (or not proceed). Again, I don't care terribly about the details of how the API looks, the above is just meant for illustration.</div>

</blockquote><div><br></div><div>I wish you had put this in its own email.  These are really two very different subjects.</div><div><br></div><div>That said, I agree with you...as long as we can do it in a manor that's completely unobtrusive and not in the "Do you want this app to work: yes or no" style (where yes implies giving them tons of permissions).  Ideally with an <input> type.  Perhaps the input could have parameters that give the "recommended" values and then leave the rest up to the UA to help advise the user?</div>

<div><br></div><div>J</div></div>