[whatwg] Proposal for Web Storage expiration

To answer a few of the questions brought up in this thread all in one bang:

1)       TTL vs. Date - I originally was going to propose a date, but the more I dug in and around uses cases for cookies, the more frequently I found people setting dates based on a TTL (i.e., I want this to expire in one year, so I add one year to the current date and set that as the expiration). It seemed that the TTL case was more common, and you could easily set an actual date via (new Date("January 1, 2011") - new Date()) if that's what you really want.
2)       Expiration for the entire data store vs. individual keys - Funny enough, my original proposal was for the entire data store, but then I went back and looked at cookies again to try to find the analogy. It seemed to me that, in the current localStorage, each key is analogous to a single cookie. Since each single cookie has an expiration, it seemed like letting each key have a separate TTL would provide parity.
3)       MAY vs. SHOULD - I could be convinced either way. The important thing, in my mind, is that the browser makes its best attempt to remove the data when specified.

-Nicholas

______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."
________________________________
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Jeremy Orlow
Sent: Friday, July 30, 2010 8:22 AM
To: Jonas Sicking
Cc: whatwg at lists.whatwg.org; Nicholas Zakas
Subject: Re: [whatwg] Proposal for Web Storage expiration

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<mailto: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/3734a55b/attachment.htm>

Received on Friday, 30 July 2010 10:45:51 UTC