W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Proposal for Web Storage expiration

From: Nicholas Zakas <nzakas@yahoo-inc.com>
Date: Mon, 2 Aug 2010 19:24:08 -0500
Message-ID: <B66541E954ECF146AD8CA69D34A283FF12CD8356E8@SP2-EX07VS02.ds.corp.yahoo.com>
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? 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.

To be clear, I think there should be expiration for all forms of client-side data storage, and adding it to one doesn't seem like a reason to not add it to all.

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: Monday, August 02, 2010 2:10 PM
To: Nicholas Zakas
Cc: Scott Hess; Alexandre Morgaut; whatwg at lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present.

If we add this to IndexedDB then there are certainly multiple storage
areas. You can have any number of objectStores inside any number of
databases.

> Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible.
>
> I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way.

If we add expiration to IndexedDB on an objectStore level, then the
page author doesn't need to do anything beyond setting an expiration
date, right?

/ Jonas
Received on Monday, 2 August 2010 17:24:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:59 UTC