- From: Mike Shaver <mike.shaver@gmail.com>
- Date: Wed, 10 Mar 2010 16:11:53 -0800
2010/3/10 Ian Fette (????????) <ifette at google.com>: > 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. It generally seems that "desktop" mail clients behave in the undesirable way you describe, in that I've never seen one warn me about available disk space, and I've had several choke on a disk being surprisingly full. And yet, I don't think it causes a lot of problems for users. One reason for that is likely that most users don't operate in the red zone of their disk capacity; a reason for THAT might be that the OS tells them that they're getting close, and that many of their apps start to fail when they get full, so they are more conditioned to react appropriately when they're warned. (Also, today's disks are gigantic, so if you fill one up it's usually a WTF sort of moment.) Part of that is also helped by the fact that they're managing a single quota, effectively, which might point to a useful simplification: when the disk gets close to full, and there's "a lot" of data in the storage cache, the UA could prompt the user to do some cleanup. Just as with cleaning their disk, they would look for stuff they had forgotten was still on there ("I haven't used Google Reader in ages!") or didn't know was taking up so much space ("Flickr is caching *how* much image data locally?"). The browser could provide a unified interface for setting a limit, forbidding any storage, compressing to trade space for perf; on the desktop users need to configure those things per-application, if such are configurable at all. If I really don't like an app's disk space usage on the desktop, I can uninstall it, for which the web storage analogue would perhaps be setting a small/zero quota, or just not going there. One thing that could help users make better quota decisions is a way for apps to opt in to sub-quotas: gmail might have quotas for contact data, search indexing, message bodies, and attachments. I could decide that on my netbook I want message bodies and contact data, but will be OK with slow search and missing attachments. An app like Remember The Milk might just use one quota for simplicity, but with the ability to expose distinct storage types to the UA, more complex web applications could get sophisticated storage management "for free". So I guess my position is this: I think it's reasonable for apps to run into their quota, and to that end they should probably synchronize data in priority order where they can distinguish (and if they were going to make some decision based on the result of a quota check, presumably they can). User agents should seek to make quota management as straightforward as possible for users. One reasonable approach, IMO, is to assume that if there is space available on the disk, then an app they've "offlined" can use it. If it hurts, don't go back to that site, or put it in a quota box when you get the "achievement unlocked: 1GB of offline data" pop-up. Mike
Received on Wednesday, 10 March 2010 16:11:53 UTC