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.<div><br></div><div>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.</div>

<div><br></div><div>J<br><br><div class="gmail_quote">On Wed, Sep 23, 2009 at 8:04 AM, Mike Hearn <span dir="ltr"><<a href="mailto:mike@plan99.net">mike@plan99.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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