[whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

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/e2c43e5c/attachment.htm>