On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas <[email protected]> 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
