W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

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

From: Mike Hearn <mike@plan99.net>
Date: Wed, 23 Sep 2009 17:04:35 +0200
Message-ID: <f4cd80640909230804o310952ffoae9bde4feb19bdcd@mail.gmail.com>
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
Received on Wednesday, 23 September 2009 08:04:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC