<div class="gmail_quote">2010/3/11 Mike Shaver <span dir="ltr"><<a href="mailto:mike.shaver@gmail.com">mike.shaver@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

2010/3/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <<a href="mailto:ifette@google.com">ifette@google.com</a>>:<br>
<div class="im">> As I talk with more application developers (both within Google and at<br>
> large), one thing that consistently gets pointed out to me as a problem is<br>
> the notion of the opaqueness of storage quotas in all of the new storage<br>
> mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the<br>
> Filesystem API being worked on in DAP, etc). First, without being able to<br>
> know how large your quota currently is and how much headroom you are using,<br>
> it is very difficult to plan in an efficient manner. For instance, if you<br>
> are trying to sync email, I think it is reasonable to ask "how much space do<br>
> I have," as opposed to just getting halfway through an update and finding<br>
> out that you hit your quota, rolling back the transaction, trying again with<br>
> a smaller subset, realizing you still hit your quota, etc.<br>
<br>
</div>It generally seems that "desktop" mail clients behave in the<br>
undesirable way you describe, in that I've never seen one warn me<br>
about available disk space, and I've had several choke on a disk being<br>
surprisingly full.  And yet, I don't think it causes a lot of problems<br>
for users.  One reason for that is likely that most users don't<br>
operate in the red zone of their disk capacity; a reason for THAT<br>
might be that the OS tells them that they're getting close, and that<br>
many of their apps start to fail when they get full, so they are more<br>
conditioned to react appropriately when they're warned.  (Also,<br>
today's disks are gigantic, so if you fill one up it's usually a WTF<br>
sort of moment.)<br>
<br>
Part of that is also helped by the fact that they're managing a single<br>
quota, effectively, which might point to a useful simplification: when<br>
the disk gets close to full, and there's "a lot" of data in the<br>
storage cache, the UA could prompt the user to do some cleanup.  Just<br>
as with cleaning their disk, they would look for stuff they had<br>
forgotten was still on there ("I haven't used Google Reader in ages!")<br>
or didn't know was taking up so much space ("Flickr is caching *how*<br>
much image data locally?").  The browser could provide a unified<br>
interface for setting a limit, forbidding any storage, compressing to<br>
trade space for perf; on the desktop users need to configure those<br>
things per-application, if such are configurable at all.  If I really<br>
don't like an app's disk space usage on the desktop, I can uninstall<br>
it, for which the web storage analogue would perhaps be setting a<br>
small/zero quota, or just not going there.<br>
<br>
One thing that could help users make better quota decisions is a way<br>
for apps to opt in to sub-quotas: gmail might have quotas for contact<br>
data, search indexing, message bodies, and attachments.  I could<br>
decide that on my netbook I want message bodies and contact data, but<br>
will be OK with slow search and missing attachments.  An app like<br>
Remember The Milk might just use one quota for simplicity, but with<br>
the ability to expose distinct storage types to the UA, more complex<br>
web applications could get sophisticated storage management "for<br>
free".<br>
<br>
So I guess my position is this: I think it's reasonable for apps to<br>
run into their quota, and to that end they should probably synchronize<br>
data in priority order where they can distinguish (and if they were<br>
going to make some decision based on the result of a quota check,<br>
presumably they can).  User agents should seek to make quota<br>
management as straightforward as possible for users.  One reasonable<br>
approach, IMO, is to assume that if there is space available on the<br>
disk, then an app they've "offlined" can use it.  If it hurts, don't<br>
go back to that site, or put it in a quota box when you get the<br>
"achievement unlocked: 1GB of offline data" pop-up.<br></blockquote><div><br></div><div>I pretty much agree with all of that, but I still think it would be useful for apps to have some concept of how much runway they have.</div>

<div><br></div><div>It might also be nice if there's a way for them to specify "these are the files that are really important to me" and "these are the files that are simply a cache" since they're two fairly different use cases.  And one of them the UA can clean up without getting user permission and one it can't.  (I've suggested something like this be added to IndexedDB anyhow.)</div>

<div><br></div><div>I wonder if we should have some way for web apps to give the browser an address for cleaning up the app's resource usage without deleting everything.  Perhaps first some UA should tackle the UI associated with file management and "uninstall" first though.</div>

</div>