[whatwg] Web Storage: apparent contradiction in spec
beidson at apple.com
Thu Aug 27 09:42:46 PDT 2009
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg