<div class="gmail_quote">On Fri, Jul 30, 2010 at 12:20 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

It might be worth integrating this into IndexedDB as it seems like<br>
people are more reluctant to add additional features to localStorage<br>
for various reasons.<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
One key question is if expiration needs to happen on a per-value<br>
basis. Or if per-storage-area (per objectStore) is enough?<br></blockquote><div><br></div><div>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.</div>

<div><br><div class="gmail_quote">On Fri, Jul 30, 2010 at 9:07 AM, Alexandre Morgaut <span dir="ltr"><<a href="mailto:Alexandre.Morgaut@4d.com">Alexandre.Morgaut@4d.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div style="word-wrap: break-word; "><div><div>To update this "expires" or "TTL" attribute of this item, I would consider</div><div><br></div><div><span style="font-family: Arial; font-size: 13px; ">Storage::setExpiration(in DOMString key, in TTL or expiration Date)</span></div>

<div><span style="font-family: Arial; font-size: 13px; "><br></span></div><div><span style="font-family: Arial; font-size: 13px; "></span><span style="font-family: Arial; font-size: 13px; ">(or </span><span style="font-family: Arial; font-size: 13px; ">Storage::setTTL() if you guys don't agree on the Date option)</span></div>

</div></div></blockquote><div><br></div><div>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?)</div>

<div><br></div><div>J</div></div></div></div><br><div>[1] Yes, I know it's specced to be non-racy, but no one implements it that way.</div>