[whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement

[Ian Hickson]

On Tue, 14 Sep 2010, Jim Williams wrote:
>
> I tried out local storage, used it to save the contents of a 
> content-editable passage.  It worked great in Firefox, Chrome, Safari, 
> and MSIE.  Only one problem: Every time I switched browsers, I had to 
> start over with the original unedited passage.  So I have two requests.
> 
> 1.  I would like the browser vendors to all use the same implementation 
> of localStorage, as this will greatly facilitate browser-independent 
> viewing experiences. As it stands, I have no idea how to maintain 
> continuity if a user viewing my page in one browser switches to another 
> browser. None.

There's only one way: have the server keep a copy. You have to do that 
anyway, since there's no guarantee the user will be using the same 
computer, let alone the same browser, the next time they visit.


> 2.  Kindly extend the specification so that other applications can make 
> constructive use of localStorage.  Specifically, (a) establish a 
> convention for associating keys with particular files (e.g., by 
> prepending the file's path name to the key), and (b) allowing other 
> applications to treat the file and its associated local storage as a 
> single entity.  Doing this would allow a user to e-mail the current 
> state of a file to a friend, so that both will have the same view of the 
> file. This ability to share "current" views of a file is useful for 
> maintaining HTML's role as a communications vehicle.

I expect we'll address this via the File System spec, if we do it.


On Tue, 14 Sep 2010, Jim Williams wrote:
>
> I see localStorage and sessionStorage as a chance to fix things that 
> weren't so good with cookies.  So I'd be interested to know what 
> factors actively promote the failure to come up with a common 
> browser-independent interface for localStorage.  Do browser builders 
> actually have something to gain by resisting interoperability here?

They save time by not having to worry about it. :-)


On Thu, 16 Sep 2010, Jeremy Orlow wrote:
> 
> Agreed.  The number of people who use only one computer but multiple 
> browsers pales in comparison to those who use multiple computers.  Thus 
> one user being able to use two browsers that share information would 
> benefit very few users (at the expense of a lot of work).  There are 
> much bigger fish to fry.

Right.


On Tue, 14 Sep 2010, Jim Williams wrote:
>
> The application I'm mainly thinking of is courseware, and it indeed does 
> need to obtain server-side copies of students' work.  But, academia 
> being what it is, these systems tend to get overused and bog down and 
> crash, inflicting furor and anguish on students and professors alike.  
> An ability for the courseware to run partly offline on student computers 
> improves reliability.  But I want students concentrating on their math, 
> not offline/online storage sharing strategies.

So store it on the server when possible, but cache it locally. That's how 
the API is intended to work. In the rare case where a user changes 
computer (or changes browser), you just redownload the data.


> Security is another consideration.  Building experimental user-server 
> exchange mechanisms isn't tolerated in my work environment, as you might 
> imagine.  So if I can use localStorage to simulate server-side storage 
> and build a proof-of-concept prototype that's entirely on the user's 
> computer [i.e., mine], I have more opportunity to demo what I'm doing.

You don't have to have working cross-browser localStorage to do a demo 
prototype. Just fake it. :-)


> Following these ideas a little further, there's good reason to retain 
> the user-side mechanisms in a production version, and just have the 
> server check and sign user successes.

What happens when the user's machine catches fire? They lose their work? 
That seems suboptimal.


> As the server-side checks succeed, the user can migrate his results to 
> other students or a professor, possibly via e-mail.  That's why I'd like 
> to have localStorage implemented in an e-mail compatible fashion.  
> Hopefully, the localStorage implementation would also be compatible with 
> dropboxes.

It's not clear to me what you're asking for here.


> But you're right about maintaining state across multiple computers.  It 
> would be nice to have a background mechanism for migrating student work 
> from one student computer to another.

That's called the server. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'