[whatwg] Resolving the persistent vs cache dilemma with file|save

[Jeremy Orlow]

Some of the suggestions in the thread were very similar to this.  If you
read it more carefully, I think you'll find answers to all your questions
and counter points to what you're suggesting.
I'm not saying there's no merit to this, but since the thread was not that
long ago, I don't think the burden should be on everyone on this list to
re-explain their points.

J

On Wed, Sep 23, 2009 at 8:04 AM, Mike Hearn <mike at plan99.net> wrote:

> Hiya,
>
> I read the threads on whether local storage should be managed by the
> browser or user with interest. I'm not sure if there was agreement on
> this or not (didn't read the whole thing), but had an idea for one
> solution. Namely, that local storage is indeed managed by the browser
> automatically and can be purged at any time .... long-term client
> persistence of web app data is instead done by letting webapps handle
> the file->save menu item that exists in nearly every browser except
> smartphones (see below).
>
> The advantages of providing onfilesave="" and onfileload="" event handlers
> are:
>
> 1) It does not add complexity, because the user isn't expected to do
> any more than they are today (no new ui to manage local storage etc)
>
> 2) It is 100% compatible with users existing mental model for how they
> export data from an application that they wish to save, back up to
> disk etc
>
> 3) It fixes the existing behavior of file|save for web apps which is
> pretty useless and not what the user expects, unlike for regular web
> pages where it does work
>
> 4) It solves the problem of client-side backups
>
> How could it work? In response to an onsave event, the app could
> return a Storage object that contains the data that makes sense to
> persist (ie, not big data files). There could be a few reserved keys
> for things like the icon, default file name and URL to open in
> conjunction with that "web bundle". If the user double clicks or uses
> file|open on such a file, the browser would load the URL named in the
> bundle file and fire the onfileload handler with that storage object.
>
> This seems like a decent compromise between the two positions, in that
> it'd let you make traditional desktop-style apps written in HTML as
> Apple want, but for pure "cloud" apps that happen to just need more
> local storage, the user isn't asked to do more than they are today -
> which I personally consider vital for the evolution of the web.
>
> What about clients where there is no user-accessible file system, like
> smartphones or perhaps ChromeOS? Then onfilesave/onfileload can be
> integrated with whatever other UI is wanted - for instance, perhaps
> starring/bookmarking should trigger a save to local storage, or a
> basic "documents associated with this web site" list could be used.
>
> What do you think?
>
> thanks -mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090923/2b32f69d/attachment-0002.htm>