- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 28 Apr 2010 15:42:45 -0700
- 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 UTC