- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Fri, 4 Nov 2011 20:10:16 +0900
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Charles Pritchard <chuck@jumis.com>, public-webapps <public-webapps@w3.org>
- Message-ID: <CAMWgRNb4mY=7UtYgsnWSiW0M3PxK4H2y4LJTWsHzEQHzLi1WBw@mail.gmail.com>
(Sorry for replying to somewhat ancient thread) On Wed, Sep 28, 2011 at 1:43 AM, Jonas Sicking <jonas@sicking.cc> 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 :) I agree that no way to persist data in the offline storage wouldn't be great and could result in bad user experience, but given the fact that most of offline data storage is used as a kind of 'cache' and that the webapp can easily detect if its data is lost or not I wonder if data loss in a (supposedly sandboxed) webapp would be that critical... or am I missing some important usage? Another concern: if we allow webapps to store data persistently by default users will need to have some nice UI for adjusting quota / deleting app data per app especially when the storage is being pressed or in an environment where storage is inherently limited (e.g. phones). Also even with such nice UI I doubt majority of users would want to manage their storage (for webapps) in that detail. What do you think about this? How is Gecko trying to solve the UI / management issue? (By the way... is there a plan to revive the 'evictable' flag anytime soon? Either one of 'all temporary' or 'all persistent' discussion might sound a bit too extreme.) Also if we want to make this API as a spec should the default storage type for each storage API be included in the spec (either in the quota one or in each API spec)? Quota has been a minor but headaching issue around web offline solution for some time. Maybe we could try making things a bit clearer based on what we've agreed / come up with so far? Thanks, / Jonas >
Received on Friday, 4 November 2011 14:08:12 UTC