I don't think there is consensus at Google yet.<div><br></div><div>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.</div>
<div><br></div><div>Here's one way such a thing could be achieved:</div><div><br></div><div><input type="storage" src="button.png" quota="20GB" /></div><div><br></div><div>When the user clicks the button they see a dialog that <a href="http://mail.google.com">mail.google.com</a> 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Linus</div><div><br><br><div class="gmail_quote">On Thu, Aug 27, 2009 at 9:42 AM, Brady Eidson <span dir="ltr"><<a href="mailto:beidson@apple.com">beidson@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div>On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote:</div><blockquote type="cite"><div style="word-wrap:break-word"><div><div>On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote:</div>
<blockquote type="cite"><div style="word-wrap:break-word"><div><div><div>To repeat what I said up above: <b>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.</b></div>
</div></div></div></blockquote></div><br><div>That makes sense to me. There might even be more than two categories:</div><div><br></div><div>- Cached for convenience - discarding this will affect performance but not functionality.</div>
<div>- Useful for offline use - discarding this will prevent some data from being accessed when offline.</div><div>- Critical for offline use - discarding this will prevent the app storing this data from working offline at all.</div>
<div>- Critical user data - discarding this will lead to permanent user data loss.</div></div></blockquote></div><div><br></div><div>I agree with Maciej's 4-level distinction on philosophical grounds, and think it's a fine list of use cases. </div>
<div><br></div><div>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.</div>
<div><br></div><div>So we're left with the "cache" vs "file" distinction once more.</div><div><br></div><div>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?</div>
<div><br></div><div>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?</div>
<div><br></div><div>"Different modes" just makes what is already a dirt simple API more complex, makes implementation more difficult for browser vendors, and confuses web developers.</div><div><br></div><div>So I resubmit my three-Storage-object solution: SessionStorage, CacheStorage, and FileStorage.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thoughts?</div><div><br></div><font color="#888888"><div>~Brady</div></font></div></blockquote></div><br></div>