- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 4 Aug 2010 10:14:28 +0100
On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking <jonas at sicking.cc> wrote: > On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas <nzakas at yahoo-inc.com> > 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. J -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100804/2b72cd27/attachment.htm>
Received on Wednesday, 4 August 2010 02:14:28 UTC