[whatwg] Web Storage: apparent contradiction in spec
whatwg at graffitiweb.org
Thu Aug 27 11:27:29 PDT 2009
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
* opensearch additions
* extension additions
This would also have the benefit of allowing a Worker() to request quota
without something on the page.
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.
> On Thu, Aug 27, 2009 at 9:42 AM, Brady Eidson <beidson at apple.com
> <mailto:beidson at 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.
More information about the whatwg