Revising Web Storage, was: Re: TAG Comment on

On 11/20/11 7:27 PM, Mike Taylor wrote:
> On Sun, 20 Nov 2011 18:30:15 -0500, Mark Nottingham <mnot@mnot.net> 
> wrote:
>
>> Yes, if you configure your browser to do so, you'll be assaulted with 
>> requests for a "test db" from many Web sites that use common frameworks.
>>
>> I don't think that this should count as "use."
>>
>> I do think now is precisely the time to be asking this kind of 
>> question; these features are NOT yet used at *Web* scale -- they're 
>> used by people willing to live on the bleeding edge, and therefore 
>> willing to accept risk of change.
>
> A quick search of Google code [1], Github [2][3], and Bitbucket [4][5] 
> would indicate otherwise, IMO. For example, the TinyMCE WYSIWYG editor 
> that is included in every Wordpress installation (currently estimated 
> at 65,787,814 sites [6]) uses localStorage for auto-saving blog posts 
> (not exactly bleeding-edge stuff). TinyMCE also boasts some of the 
> most successful and popular sites on the web as users [7]. And that's 
> just one single project from the many thousands of open source 
> projects hosted by Google Code, Bitbucket or Github.
>

I'm a full-stack polyfill over here. From the bare bones of the 
server-side to the legacy hacks of the client.

As I voiced earlier in this thread: I'd rather extend than rewrite. 
localStorage could use a Blob storage mechanism. I could really use 
that. The FileSystem API is completely inappropriate for most blob 
storage needs and other APIs fail support Blob's in an efficient manner. 
Is there some reason why I can't have a blob extension to local 
storage:  localStorage.setBlob('key', BlobData);

As for existing code bases: localStorage throws errors. Few people are 
going around with try { localStorage['key'] = 'value'; } catch(e) {} 
statements. Though people are certainly testing for the presence of 
localStorage, it's rather assumed that if it is present, it can be 
written to, with at least a few hundred kilobytes of textual data. That 
assumption will break if the API is dropped or significantly altered.

In subsequent APIs, like IndexedDB, spec editors took care to avoid that 
error throwing situation.

...

Web Storage is very different from typical storage. It's not an 
expectation for a web app that it'll actually have space to store data. 
There's no guarantee the data will persist. We do not yet have mount 
points, to stash data on the user's file system in a manner that the 
user and the OS understand.

Storage is as transient as client-side cookies. With a few clicks, I can 
accidentally clear out saved files when I'm just trying to reset my 
cache. My databases may become corrupt when the browser crashes on a 
complex page I'm testing. I have no "easy" way to back up my data as I 
do with most files on my computer. I can't just copy and paste files 
into a new directory.

Web storage is fault-oriented. It's supposed to fail. It's designed for 
failure. It's up to application authors and UA vendors to decide what 
kind of value-added services they want to give to their users, to help 
back up data. It's up to users to take opportunities to copy data out 
themselves and archive it in their own manner. This is stressful to me, 
as a developer, because Apple, Google can wipe out a business model in 
any given browser release, but that's the business we're in.

I am bringing this up to point out that, although web storage is out 
there, in production, there's room to destroy data. It's not a happy 
situation, and it's one that many developers will learn the hard way (as 
I did). But once it's accepted, it's easier to understand how to use web 
storage in a safe manner.

-Charles

Received on Monday, 21 November 2011 04:34:17 UTC