- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 20 Apr 2010 15:57:59 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Nikunj Mehta <nikunj@o-micron.com>, Michael Nordman <michaeln@google.com>, public-webapps@w3.org, João Eiras <joaoe@opera.com>, Mark Seaborn <mseaborn@chromium.org>
On Tue, Apr 20, 2010 at 3:19 PM, Jeremy Orlow <jorlow@chromium.org> wrote: > This way of thinking is incompatible with offline web apps. If I'm offline > and I "send" and email, it needs to stay queued up to send until I'm > reconnected to the internet. > > Anyone wanting to debate whether or not the UA should be free to clean up > "persistent storage" without asking the user should read > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 and > the various other threads it spawned first and only re-start things if they > have new information to add. Indeed. Per the other thread, a relatively simple approach that keeps popping up, and which Michael raised here as well, is the idea of splitting up storage into just two basic categories: transient/purgable/cache/short-term and long-term/"permanent". These two categories represent, I believe, the most useful distinction, because these are categories that we can then translate directly into differing UA behaviors. Transient storage doesn't need a user's direct input to be used. Much like cookies, by default sites can use transient storage silently and as much as they want. However, the UA is free to put whatever limits it desires on total transient storage available, and have whatever cache eviction policies it wants in order to cull space when things start to get full. The only thing we may want to provide to the app is a way to query "probably available space". This would tell the app approximately how much space the UA estimates the app can use before risking running into problems. It is only an estimate, however. This sort of information is necessary for an app to be able to distinguish between a desktop browser with a full-sized hard drive, a mobile browser with limited space, and a device with no long-term storage. It also allows direct interaction with user preferences, so that a user may choose between the easily-understandable options of "Lots of Space", "Limited Space", and "No Space" as the default grant to webapps. Permanent storage *does* need a user's direct input. This should *not* be through a script-originated modal dialog. The best way to trigger something through user input is to use the markup designed to capture user input - <input>s! There are various ways that this sort of thing can be usefully exposed. For things like LocalStorage and IndexedDatabase, the user would interact with a specialized <input> that would create an appropriate storage space and fire some event. For things like FileWriter, we could instead expose an ordinary Save File dialog which would act similarly. The common thread is just that the user directly activates something on their own, and *only then* is presented with a dialog of some kind to decide on the specific options. This is the place where requesting quotas can be useful. Apps can be built to use both kinds of storage seamlessly this way. An email app, frex, can by default save drafts in temporary storage (no need to ask the user, but subject to eviction), but if the user grants it file access, it can instead save them into a directory structure on the hard drive. This sort of approach also addresses the issues brought up in the OP. An app needing a large grant can just ask the user to click on an <input type=storage quota=1G> button, which is relatively safe. Simultaneously, an evil app can't really exploit any holes in the grant procedure, because the only storage it gets automatically is implicitly both transient and subject to UA automatic controls. Worst case, a UA doesn't do anything special and the evil site just clobbers all the other temporary storage. Best case, the UA uses an intelligent eviction algorithm that makes more established data more resistant to eviction. Making this sort of distinction means, of course, that *all* currently specified storage types are transient. ~TJ
Received on Tuesday, 20 April 2010 22:58:51 UTC