W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Granting storage quotas

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 28 Apr 2010 15:42:45 -0700
Message-ID: <y2v63df84f1004281542gea4c8f29m771750a9bce3923d@mail.gmail.com>
To: Dumitru Daniliuc <dumi@chromium.org>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, Michael Nordman <michaeln@google.com>, Mike Clement <mikec@google.com>, public-webapps@w3.org
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 definitely realize that automatically expiring data stored in
IndexDB needs to be done with much care. Whatever the spec says,
developers will likely think of the storage area as basically
permanent. So we'll likely need to experiment with the expiring a good
deal.

Ultimately it probably doesn't make sense to have MUST requirements
around this as this can't be tested anyway. I.e. there is no way to
test that data put in the storage won't be expired in half a year. It
might make sense to have some informal language in the spec so that
authors have some idea of how this works, but for now we have no
language to recommend since we'd like to get implementation
experience.

Again, this is similar to how cookies work, where we (and I believe
other browsers), have played around with different expiration policies
throughout the years.

/ Jonas

On Wed, Apr 28, 2010 at 2:54 PM, Dumitru Daniliuc <dumi@chromium.org> wrote:
> shawn, did you have a chance to give this some thought? how would mozilla
> like to handle cases like the ones jeremy and robin mentioned? how would you
> like to manage quotas?
>
> thanks,
> dumi
>
>
> On Fri, Apr 23, 2010 at 11:08 AM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
>>
>>  On 4/23/2010 7:39 AM, Nikunj Mehta wrote:
>>>
>>> Could we create an additional optional parameter for an open request with
>>> the type of permanence required? Or is it not a good idea?
>>
>> I haven't talked to anyone at Mozilla that thinks that having permanent
>> and non-permanent-but-possibly-long-lasting data to be a good idea.  There
>> does seem to be support for a session-only version of indexedDB.
>>
>> Cheers,
>>
>> Shawn
>>
>
>
Received on Wednesday, 28 April 2010 22:43:39 GMT

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