[whatwg] Proposal for local-storage file management

[Jens Alfke]

[This is a spin-off of "Web Storage: apparent contradiction in spec".  
I'm starting a new thread to make a specific proposal.]

I agree that where possible we should find a way to do things without  
adding Mother-may-I dialog boxes. But I also believe we need some user  
interaction to enable a site to store nontrivial amounts of permanent  
local data, to avoid Linus's griefer scenario. Conundrum.

But maybe the user interaction can be made to fit into existing  
familiar workflows. In a traditional document-based UI, the app  
prompts the user with a standard Save dialog box when it needs to  
create a new data storage area (a "file"). A default name and location  
are filled in, but the user can customize, or of course hit Cancel.

Why not re-use that same model for HTML5 local storage? After all, we  
know the data is going to end up in the filesystem, so why not let the  
user pick where to put it? This way every web-app gets a separate  
local file. Internally it's probably a sqlite database or DBM file or  
whatever, but that's unimportant. The user follows the age-old save-a- 
file workflow to create one, so s/he is in control of whether it's  
created and where it goes. It gets backed up along with the user's  
other data. The user can trash it later on to make room or for privacy  
purposes.

Here's what a typical scenario might look like:
Ellen tells me about a great online animation program. I go to its  
site, and it puts up a Canvas and a bunch of snazzy drawing tools, so  
I start sketching frames of an animation. (Behind the scenes, the app  
is storing my drawings in session storage. This is considered  
temporary, so the browser gives it a reasonable quota without any user  
interaction.)
After a while I decide I want to keep using the app, and the stuff  
I've drawn has potential, so I decide to save it to disk. I click the  
Save button, and the site (actually the browser) puts up a standard  
Save dialog box. (Behind the scenes the JS code is writing a value to  
persistent local storage, and since no storage exists yet for its  
domain, the browser is prompting the user.)
The dialog's prompt is something like "Save SooperAnimator.com data  
as:", and the initial destination is "~/Documents/Web Documents/ 
SooperAnimator.com Data". I hit Enter and my animation is saved.  
(Behind the scenes the browser created a new local-storage file at  
that location, and remembered where it put it.)
Next month I remember that animation in progress and go back to the  
site. My work appears just the way I left it. (The site's script  
accessed its persistent storage, so the browser looked up where it put  
the file and opened it.) I do some more work on it; this time as I  
save (or maybe it auto-saves) the data gets written to the storage  
file without any more interaction because the file already exists.
Next year I've switched allegiance to UltraAnimate.com, so while  
cleaning house I go through my Web Documents folder, see the old  
"SooperAnimator.com Data" file, and trash it to save disk space.

This seems to end up as a combination of the local storage API with  
some of the behavior of the filesystem access proposal (which to be  
honest I haven't read yet.) In essence the entire local storage object  
space is implemented as a key-value DB file.

Does this seem reasonable?

—Jens