[whatwg] Proposal for local-storage file management

[Ian Fette (イアンフェッティ)]

Not sure I agree with limiting it to the duration of the page. For instance,
if I'm Flickr, I want to be able to get access to the "My Photos" directory
and monitor it for new photos being added. Additionally, if I've given you
access to the directory once, you can do most of the damage you want with
that one-time access.
The existing API has a parameter on many of the functions called
"persistent" - I think the challenge is how to surface that in a reasonable
UI. I believe though that it is worth trying.

>From the proposal -

The last argument to browseForDirectory is a Boolean argument determining
whether the mountpoint is to be made persistent across restarts of the
application. If this argument is missing, it is assumed to be present, with
a default value of false. If the argument is true then the File object must
be marked as persistent.

2009/8/27 Linus Upson <linus at google.com>

> I like this proposal. It was what I had in mind with <input type="open">
> and <input type="save">. The only small change I'd make is that the page can
> only maintain a reference to the file for the life of that page. After that,
> the user needs to click open again. The open and save dialogs may remember
> recent files to make it easy for the user.
>
> Linus
>
>
> 2009/8/27 Jens Alfke <snej at google.com>
>>
>>> [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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090827/e9e76efa/attachment-0001.htm>