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.
