[whatwg] Web Storage: apparent contradiction in spec

[Linus Upson]

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 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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090827/1df8d6f3/attachment.htm>