[whatwg] Proposal for Web Storage expiration

It might be worth integrating this into IndexedDB as it seems like
people are more reluctant to add additional features to localStorage
for various reasons.

One key question is if expiration needs to happen on a per-value
basis. Or if per-storage-area (per objectStore) is enough?

/ Jonas

On Thu, Jul 29, 2010 at 10:57 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Background:
>
>
>
> The Web Storage specification provides two ways for web applications to
> store key-value data in the browser, effectively replacing cookies for cases
> when the server doesn?t need the information. For a lot of web application
> needs, sessionStorage and localStorage (or some combination of the two) can
> be used to effectively reduce the number of cookies used. Cookies do have
> one advantage over these APIs: the ability to specify an expiration period
> after which the data is removed.
>
>
>
> Right now, if a web application developers wish to have expiration of
> key-value pairs, he/she must manually implement such expiration on their
> own. An example of an API that already does this is XAuth (xauth.org).
>
>
>
> Proposal:
>
>
>
> Adding the ability to optionally define an expiration date for each
> key-value pair would bring sessionStorage/localStorage closer the
> capabilities of cookies today and provide useful control over the length of
> time that certain data can live in the browser. This becomes especially
> important if any authentication-related data is to be stored in Web Storage.
>
>
>
> Proposed Interface Change:
>
>
>
> The easiest way to include such a change would be to augment the
> Storage::setItem() method with a third optional argument. So change from:
>
>
>
> ??? setter creator void setItem(in DOMString key, in any data);
>
>
>
> To:
>
>
>
> ??? setter creator void setItem(in DOMString key, in any data, [Optional] in
> unsigned long ttl);
>
>
>
> The third argument is a TTL specifying how long, in milliseconds, the data
> should be stored in sessionStorage/localStorage. Some proposed
> implementation details:
>
> * A TTL of 0 is considered invalid and ignored, as is any value less than 0.
> If you want to immediately remove a key, it should be done via removeItem().
>
> * The TTL for a key may be changed each time setItem() is called, with the
> new TTL overwriting the old one.
>
> * If a TTL was previously set, and then a new TTL is not provided on a
> subsequent call to setItem(), then the original TTL remains.
>
> * If a TTL was previously set, and another call is made to setItem() that
> contains an invalid TTL (<= 0), then the original TTL remains.
>
> * To remove a previously set TTL, you must call removeItem() to completely
> remove the key and then re-add using setItem().
>
> * Adding a third argument means the length property of setItem will be 3, so
> developers can check for support of this feature using
> (localStorage.setItem.length > 2).
>
> * The TTL is valid for both sessionStorage and localStorage, but more
> important for localStorage.
>
>
>
> Thoughts?
>
>
>
> -Nicholas
>
>
>
> ______________________________________________
>
> Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
>
> Morpheus: "My beliefs do not require them to."
>
>

Received on Friday, 30 July 2010 04:20:57 UTC