W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Storage Quota API

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 27 Sep 2011 13:26:04 -0700
Message-ID: <4E82315C.3050804@jumis.com>
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 GMT

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