- From: Alexandre Morgaut <Alexandre.Morgaut@4d.com>
- Date: Fri, 30 Jul 2010 10:07:27 +0200
On Jul 29, 2010, at 7:57 PM, Nicholas Zakas wrote: > 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); I think too that being able to specify the end of life of stored data can be useful I also think, like Paul Ellis it might be frustrating to have too set again the value of an item to update its TTL value (all the more on very large Objects) Another frustration for me is to have to set a TTL value when the value I want to defined is a fixed expiration date and not a "Time To Live" value. I'd prefer then: - to call this third argument "expires" - make this argument considered as a TTL value if it is a number - make this argument considered as an expiration date if it is a Date Object - it might also be considered as an expiration Date if it is a ISO Date String (often used in JSON string) - it might then be considered as a TTL if it is not an ISO Date String but a string that can be converted into a valid number About negative, null value of a value equal too 0 assigned to this third argument: -> I agree with Paul that it could be interpreted to remove this expiration setting About interpreting no value to the second argument as a TTL update -> I find it kind of weird What is the expected behavior when setting an item value to undefined ? I find it unclear in the specification. It says setItem fix a structured clone value... -> will it throw an exception for undefined -> will it remove the item as we could expect using the alternative way to set the value (localStorage.myItem = undefined) Thinking about JSON stringification, setting a property to undefined makes it disappear while null preserves its existence. Thinking about Objects, assigning null would is often used to delete an instance (even if I semantically prefer the "delete" JavaScript instruction) To update this "expires" or "TTL" attribute of this item, I would consider Storage::setExpiration(in DOMString key, in TTL or expiration Date) (or Storage::setTTL() if you guys don't agree on the Date option) By the way, I often figure out that one on the goals to define good APIs is to "Keep It Stupid Simple" ;-) So I could live, maybe a bit sadly, without the support of Dates... Alexandre. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100730/292d9dad/attachment.htm>
Received on Friday, 30 July 2010 01:07:27 UTC