-1 No, we should keep widget.preferences.
If a UA wants to, it can simply implement it using: widget.preferences = window.localStorage;If it doesn't, the UA can do its own implementation, which we do for example, as for our UA localStorage is not an appropriate implementation, as our users are more likely to interact with the same widget using multiple browsers on multiple machines. We can also implement widget.preferecences. We can't reimplement the user's browser's WebStorage impl (if it has one).
For more detailed arguments for keeping preferences, just search back through the list ;-)
(We've already argued this one loads of times, Marcos! Why has it come up again?)
S On 20 Jul 2009, at 15:08, Marcos Caceres wrote:
In the widgets API spec, what are the advantages of having a
widgets.preferences attribute when the window.localStorage is already
available on the window object?
I think we should:
1. Drop widget.preferences, but require a UA to implement
[WebStorage] (which we already do!).
2. Pre-populate the window.localStorage with the value of
<preference> elements in the config document (no events are fired
during pre-population!).
3. "Protect" read-only preferences, meaning:
A. At runtime, throw a NO_MODIFICATION_ALLOWED_ERR exception
upon any attempt to invoke the setItem() or removeItem() methods.
B. upon the attempted invocation of the clear() method, a user
agent must not remove the key-values of the protected preference from
a storage area.
WDYT?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
smime.p7s
Description: S/MIME cryptographic signature
