There should also be a way to ask for more quota (from the user) without losing user data.
The API via a form element is a little odd--generally forms are for submitting information to the site. Historically, all of these kinds of things are done via javascript: * cookies * opensearch additions * extension additions This would also have the benefit of allowing a Worker() to request quota without something on the page. cheers, Schuyler Linus Upson wrote: > I don't think there is consensus at Google yet. > > I'm not saying that UAs shouldn't provide file-like lifetime semantics > for storage. I'm just saying the user should decide, not the web page. > > Here's one way such a thing could be achieved: > > <input type="storage" src="button.png" quota="20GB" /> > > When the user clicks the button they see a dialog that mail.google.com > <http://mail.google.com> would like to use 20GB of storage. You have > 50GB of free space. [Yes] [No]. Script can't cause the dialog to appear, > only a user action. There would also be some affordance in that dialog > to allow the user to manage persistent storage from other domains. A > small "Other sites are using 2GB of storage" link perhaps. AppCache, > LocalStrorage, and all other persistent bits for that domain would live > within this quota. UAs would take this user action as a strong signal > that the data is valuable and would act accordingly. > > If web sites use LocalStorage, AppCache, et. al. without the user > clicking on and accepting a storage input button, then the UA would be > free to garbage collect as it sees fit. Good UAs would do a good job of > not throwing away things that are important to the user, just as they do > today with cookies. > > Linus > > > On Thu, Aug 27, 2009 at 9:42 AM, Brady Eidson <beid...@apple.com > <mailto:beid...@apple.com>> wrote: > > On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote: >> On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote: >>> To repeat what I said up above: *Maybe the local storage API >>> needs a way to distinguish between cached data that can be >>> silently thrown away, and important data that can't.* >> >> That makes sense to me. There might even be more than two categories: >> >> - Cached for convenience - discarding this will affect performance >> but not functionality. >> - Useful for offline use - discarding this will prevent some data >> from being accessed when offline. >> - Critical for offline use - discarding this will prevent the app >> storing this data from working offline at all. >> - Critical user data - discarding this will lead to permanent user >> data loss. > > I agree with Maciej's 4-level distinction on philosophical grounds, > and think it's a fine list of use cases. > > But I think there's been a reasonable amount of agreement on this > list that it is unnecessarily fine grained. A developer who is > consciously choosing a cache will always choose the "most > aggressive" cache, and a developer who is consciously choose file > storage will always choose the "most sacred" file storage. > > So we're left with the "cache" vs "file" distinction once more. > > All browser vendors who have implemented LocalStorage are willing to > implement the "cache", because what they've done either meets or > exceeds the cache use-case. The remaining question is the file > storage. How do we implement this distinction? > > I don't like the idea of having "different modes" on LocalStorage. > How would the "different mode" be triggered? How would it be > managed? What happens when two applications from the same security > origin try to mix modes? > > "Different modes" just makes what is already a dirt simple API more > complex, makes implementation more difficult for browser vendors, > and confuses web developers. > > So I resubmit my three-Storage-object solution: > SessionStorage, CacheStorage, and FileStorage. > > From this discussion, it appears that FileStorage is something > Google might not be willing to implement. That's fine! They can > have the object available to scripts but just give it a zero quota. > To be more friendly to developers and not force them into checking > abilities by catching exceptions we could add one more property to > the storage interface so they can check ahead of time whether their > attempt to store data will fail. > > Web developers would then have the ability to make the conscious > decision of "Is a cache good enough?" and fallback to CacheStorage, > or decide "No, I really need persistent data" and fallback to Flash > or some other plug-in. The interfaces are all so similar as to be > pretty painless for the developer. > > Thoughts? > > ~Brady > >