<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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><div>~Brady</div></body></html>