- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 27 Sep 2011 13:26:04 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Kinuko Yasuda <kinuko@chromium.org>, public-webapps <public-webapps@w3.org>
On 9/27/2011 9:43 AM, Jonas Sicking wrote: > On Tue, Sep 27, 2011 at 6:12 AM, Kinuko Yasuda<kinuko@chromium.org> wrote: >> Just to confirm: Yes the interfaces are vendor prefixed (WebKit), and >> WebSQL, AppCache, IDB are treated as temporary in the current chromium >> implementation. >> On Tue, Sep 27, 2011 at 8:53 AM, Charles Pritchard<chuck@jumis.com> wrote: >>> Any ideas on how to express temp v. Perm to IndexedDB? >> IIRC there's been a proposal to have a way to hint that an IndexedDB >> ObjectStore is 'evictable' or not: >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11350 >> Though it seems to be put off until later (version 2), I was assuming that >> once we have the 'evictable' option it would indicate the data's Temp/Perm >> attribute. >> Other storage APIs do not have a way to express temp/perm either. >> Chromium's current policy is defaulting to conservative or less >> astonishment to the users (in our belief), so that they won't see unexpected >> prompts or unknown data pressing their disk space. > And instead getting unexpected data loss :) What does happen in Chrome? From what I've seen, the AppData directory continues to balloon. I had an old SSD, about 32Gigs: Chrome is pretty liberal in its use of disk space. Short of the user clearing their history, I've not quite understood when and how the temporary caches vacate. Now that we are targeting Chromebooks, the "unexpected data loss" scenario is something that's getting baked into the application ux. -Charles
Received on Tuesday, 27 September 2011 20:26:27 UTC