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

[whatwg] Proposal for Web Storage expiration

From: Nicholas Zakas <nzakas@yahoo-inc.com>
Date: Thu, 29 Jul 2010 10:57:54 -0700
Message-ID: <B66541E954ECF146AD8CA69D34A283FF12CD675099@SP2-EX07VS02.ds.corp.yahoo.com>
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."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100729/61b88682/attachment.htm>
Received on Thursday, 29 July 2010 10:57:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC