<div class="gmail_quote">On Tue, Aug 3, 2010 at 1:51 AM, 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;">

<div class="im">On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <<a href="mailto:nzakas@yahoo-inc.com">nzakas@yahoo-inc.com</a>> wrote:<br>
> Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage?</div></blockquote><div><br></div><div>No.  I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies.  IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage.<br>


<br>
</div>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></blockquote><div><br></div><div>Jonas, are you against the expiration feature proposal for LocalStorage?  Because no one else has voiced the typical "we should just leave LocalStorage alone" concerns.  So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern.</div>

<div><br></div><div>I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases.</div><div><br></div><div>J</div></div>