As far as I can see, the next steps are (roughly in order):<div>1) Figure out whether it should be an origin wide setting or not.  In order to prove that it needs to be a per LocalStorage bucket setting, its on you to come up with use cases where an origin wide setting is not enough.  By use cases, we mean specific examples of stuff that clearly happens in reality today or would happen in reality if this was added.</div>

<div>2) Come up with a concrete proposal for what be added to the spec.</div><div>3) Find a UA willing to prototype such a new feature.</div><div><br></div><div>At any point, it's possible Ian may be interested in adding it to the WebStorage spec and/or others could follow your lead.  But if I were you, I'd start down the road I just described.</div>

<div><br></div><div>J<br><br><div class="gmail_quote">On Thu, Aug 5, 2010 at 1:55 AM, Nicholas Zakas <span dir="ltr"><<a href="mailto:nzakas@yahoo-inc.com">nzakas@yahoo-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

So given no strenuous objections, can we make expiration for Web Storage real? :)<br>
<div class="im"><br>
-Nicholas<br>
<br>
______________________________________________<br>
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"<br>
Morpheus: "My beliefs do not require them to."<br>
<br>
-----Original Message-----<br>
</div><div class="im">From: Jonas Sicking [mailto:<a href="mailto:jonas@sicking.cc">jonas@sicking.cc</a>]<br>
</div><div class="im">Sent: Wednesday, August 04, 2010 10:26 AM<br>
To: Jeremy Orlow<br>
Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; <a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a><br>
Subject: Re: [whatwg] Proposal for Web Storage expiration<br>
<br>
</div><div><div></div><div class="h5">On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking <jonas@sicking.cc> wrote:<br>
>><br>
>> On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <<a href="mailto:nzakas@yahoo-inc.com">nzakas@yahoo-inc.com</a>><br>
>> wrote:<br>
>> > Yes, for IndexDB I think having a per-storage area expiration date<br>
>> > completely makes sense. Do you expect that IndexedDB will become a successor<br>
>> > to sessionStorage/localStorage?<br>
><br>
> No.  I think LocalStorage will stick around since it's just so simple to use<br>
> and a lot of people just need to store a tiny bit of data here or<br>
> there--much like cookies.  IndexedDB will be used for structured data, so I<br>
> don't see many people using it for things they one used (abused) cookies<br>
> for.<br>
><br>
>><br>
>> My belief is that the simple key-value store paradigm would still end up<br>
>> being the default client-side data storage utility, and would therefore<br>
>> benefit from having a per-key expiration time to mimic cookie usage.<br>
>><br>
>> I suspect it will be much easier to add to IndexedDB than to<br>
>> localStorage/sessionStorage. I don't expect the latter to go away,<br>
>> though generally it seems like people are disliking localStorage<br>
>> enough that it's hard to get any changes made to it.<br>
><br>
> Jonas, are you against the expiration feature proposal for LocalStorage?<br>
>  Because no one else has voiced the typical "we should just leave<br>
> LocalStorage alone" concerns.  So if you're not, I think we can assume that<br>
> such types (me included) aren't going to raise such a concern.<br>
> I'm actually much less enthusiastic about expiration for IndexedDB as I<br>
> don't see very compelling use cases.<br>
<br>
I'm definitely for expiration of localStorage values. Though I think<br>
it also makes sense to do for IndexedDB. Especially if it can be done<br>
on a per-objectStore basis as that makes it very low overhead.<br>
<br>
/ Jonas<br>
</div></div></blockquote></div><br></div>