On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow <[email protected]> wrote: > On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking <[email protected]> wrote: >> >> On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <[email protected]> >> wrote: >> > 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? > > 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. > >> >> 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. >> >> I suspect it will be much easier to add to IndexedDB than to >> localStorage/sessionStorage. I don't expect the latter to go away, >> though generally it seems like people are disliking localStorage >> enough that it's hard to get any changes made to it. > > 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. > I'm actually much less enthusiastic about expiration for IndexedDB as I > don't see very compelling use cases.
I'm definitely for expiration of localStorage values. Though I think it also makes sense to do for IndexedDB. Especially if it can be done on a per-objectStore basis as that makes it very low overhead. / Jonas
