W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] Proposal for Web Storage expiration

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 30 Jul 2010 16:22:08 +0100
Message-ID: <AANLkTi=ioB4wRip89eh0huXy==uukWZdYvtF4kHVBa-u@mail.gmail.com>
On Fri, Jul 30, 2010 at 12:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> It might be worth integrating this into IndexedDB as it seems like
> people are more reluctant to add additional features to localStorage
> for various reasons.
>

I have expressed this opinion quite vocally in the past, but given that
expiration is an ability of cookies, cookies suffer from the same race
conditions localStorage does [1], and giving people fewer reasons to depend
on cookies is definitely good for the web (in terms of bandwidth and
latency), I actually think we should go ahead with something like this.

The main thing is that it'd need to be specced as a MAY condition.  I.e. the
browser MAY delete the content once it expires.  After all, if the user
never turns on the computer, there's no possible way for the UA to delete
the data.  It'd then be up to the UAs to decide how agressive they'd like to
be about deleting it.

I'd suggest moving forward looking at expiration for WebStorage first and
then evaluate it for IndexedDB later on (since there's still a lot of more
important stuff in the air with that spec right now).


> One key question is if expiration needs to happen on a per-value
> basis. Or if per-storage-area (per objectStore) is enough?
>

Good point.  Several of the use cases I can think of seems as though they
might be solvable with just a global setting.  Unless there's a couple use
cases where this seems fairly compelling, maybe we should concentrate on
such a solution.

On Fri, Jul 30, 2010 at 9:07 AM, Alexandre Morgaut <Alexandre.Morgaut at 4d.com
> wrote:
>
> To update this "expires" or "TTL" attribute of this item, I would consider
>
> Storage::setExpiration(in DOMString key, in TTL or expiration Date)
>
> (or Storage::setTTL() if you guys don't agree on the Date option)
>

This might make sense, but I'm also not sure it's worth the additional API
surface area.  Plus I kind of like the idea of making it difficult for
people to detect whether the browser even supports expiration since we don't
people to ever assume they can count on it.  (Since once again, what if the
user doesn't turn on their computer or the UA doesn't delete expired data
unless it's running?)

J

[1] Yes, I know it's specced to be non-racy, but no one implements it that
way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100730/3d4eb508/attachment-0001.htm>
Received on Friday, 30 July 2010 08:22:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC