[whatwg] Web Storage: apparent contradiction in spec

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 <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.
> 
>     Thoughts?
> 
>     ~Brady
> 
>

Received on Thursday, 27 August 2009 11:27:29 UTC