Re: [IndexedDB] Granting storage quotas

On Wed, Apr 28, 2010 at 4:03 PM, Michael Nordman <michaeln@google.com> wrote:
> This thinking resonates with what we've been thinking too (I think).
>
> On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> We had some discussions about this at mozilla yesterday. I think the
>> summary is something like this:
>>
>> * We'd like to expire data in IndexDB after some time. This will
>> likely be based on heuristics, such as haven't visited the site for an
>> extended period of time, though possibly keep the data a bit longer if
>> it was put in the database during offline mode and thus likely
>> contains data from the user. So in other words, we'd like to prevent
>> data staying on the users system indefinitely for a site that the user
>> no longer uses.
>> * We'll expose UI to allow the user to remove data at any point.
>> Similar to cookie UIs.
>> * We'll expose APIs to extension developers to allow extensions to
>> manage data lifetime as well, similar to cookie APIs.
>> * We support the idea of temporary object stores used to for example
>> implement cross joins. One solution is that these as never inserted
>> into a database, but are only useable if you have a reference to a
>> store object. Once the storage object is no longer used and is GCed,
>> the store is nuked.
>> * There was some support for non-permanent-but-possibly-long-lasting,
>> useful for for example caching data that is also available on the
>> server. The main concern here was that sites will always just opt for
>> the most permanent storage option. So we need to ensure that there is
>> incentive not to do this.
>
> We have in mind that the incentives for developers to not always utilize the
> most permanent storage option are...
> 1) Non-permanent storage is accessible w/o explicit user opt-in, so less
> annoying UI.

This is interesting. I think that we'll want to allow sites some
amount of permanent storage without explicit user opt-in. Though we
could allow much more for the "caching storage". This sounds like a
very good idea.

> 2) Less of a burden to 'manage' the data if the user-agent will clean it up
> for you.

I'm not convinced this will be much of incentive. I think few sites
are as interested in cleaning up the users hard drive as the user is.
I can see many sites dropping data into the permanent storage and then
caring very little when that is cleaned up. I'd imagine many ad
networks would love it if it was never cleaned up.

The incentive I had in mind was that if the UA decides it needs to
purge data for a specific site, for example due to hitting some global
quota, then we'd first clear out the data with the lowest level of
permanence first. So it wouldn't make a difference if all data for a
site is permanent, or if all of it is semi-permanent, in both cases
it'd all get nuked.

However if the site has some permanent and some semi-permanent, then
we'd clear out the semi-permanent first and remeasure if we're up
against the global quota still.

But I also really like the idea of having less UI for semi-permanent.

/ Jonas

Received on Wednesday, 28 April 2010 23:33:16 UTC