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-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Jeremy Orlow
Sent: Friday, July 30, 2010 8:22 AM
To: Jonas Sicking
Cc: whatwg@lists.whatwg.org; Nicholas Zakas
Subject: Re: [whatwg] Proposal for Web Storage expiration
On Fri, Jul 30, 2010 at 12:20 PM, Jonas Sicking <jo...@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.morg...@4d.com<mailto:alexandre.morg...@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.
