[whatwg] Proposal for Web Storage expiration

[Jeremy Orlow]

As far as I can see, the next steps are (roughly in order):
1) Figure out whether it should be an origin wide setting or not.  In order
to prove that it needs to be a per LocalStorage bucket setting, its on you
to come up with use cases where an origin wide setting is not enough.  By
use cases, we mean specific examples of stuff that clearly happens in
reality today or would happen in reality if this was added.
2) Come up with a concrete proposal for what be added to the spec.
3) Find a UA willing to prototype such a new feature.

At any point, it's possible Ian may be interested in adding it to the
WebStorage spec and/or others could follow your lead.  But if I were you,
I'd start down the road I just described.

J

On Thu, Aug 5, 2010 at 1:55 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:

> So given no strenuous objections, can we make expiration for Web Storage
> real? :)
>
> -Nicholas
>
> ______________________________________________
> Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
> Morpheus: "My beliefs do not require them to."
>
> -----Original Message-----
> From: Jonas Sicking [mailto:jonas at sicking.cc]
> Sent: Wednesday, August 04, 2010 10:26 AM
> To: Jeremy Orlow
> Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; whatwg at lists.whatwg.org
> Subject: Re: [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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100805/e1a13c5a/attachment-0002.htm>