Re: [IndexedDB] Granting storage quotas

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.

Just to clarify: you're looking to expire storage that's marked as
persistent [or something like that] or that's marked as temporary, or
you're not planning to distinguish strongly between types of storage?

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

Indeed.  As Michael said, we're looking at linking persistence to
whether or not the user has been asked for permission.  Surprising
developers is a bad thing, but surprising users by deleting stuff
they've explicitly asked us to save is worse.  The users may not
always be able to tell the difference, but the more explicit we can
make the split between storage types, the fewer such losses we'll
have.

> 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 23:18:19 UTC