W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Storage Quota API

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Fri, 4 Nov 2011 20:10:16 +0900
Message-ID: <CAMWgRNb4mY=7UtYgsnWSiW0M3PxK4H2y4LJTWsHzEQHzLi1WBw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Charles Pritchard <chuck@jumis.com>, public-webapps <public-webapps@w3.org>
(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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT