[whatwg] Proposal for Web Storage expiration

On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> 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.

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

Received on Wednesday, 4 August 2010 10:25:54 UTC