W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [widgets] localStorage vs preferences

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 20 Jul 2009 17:32:29 +0200
Message-ID: <4A648E0D.5030705@opera.com>
To: Robin Berjon <robin@berjon.com>
CC: public-webapps <public-webapps@w3.org>

On 7/20/09 4:45 PM, Robin Berjon wrote:
> On Jul 20, 2009, at 16: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?
> I think it's dodgy. Basically this would mean reusing a well-known
> attribute but giving it different behaviour, which in general is a bad
> idea. The "vanilla" localStorage would never throw in such ways, and
> would clear() the protected preferences.

Not if we said it couldn't:)

> This change means that
> localStorage won't work the same way for a given document if that
> document is in a widget or not. I don't think that's a good idea.

Fair enough.

> The cost of having preferences there is very low, and it makes sense
> semantically. Why remove it?

Ok, so, widget.preferences MUST NOT equal window.localStorage. The are 
separate things. Both can be used. Right?

Kind regards,
Received on Monday, 20 July 2009 15:33:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:17 UTC