Re: [IndexedDB] Granting storage quotas

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.
2) Less of a burden to 'manage' the data if the user-agent will clean it up
for you.


> 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
> >>
> >
> >
>