Re: [widgets] dropping Asynchronous HTTP Requests and Storage

These are common practices that are ready to be standardised to  
realize a benefit for widget developers and widget users.

The argument of "user agents having to support two storage mechanisms  
for widgets" is a strawman: the cost for a UA to support the Widget  
Preferences (Storage) API and wire it to their existing storage  
implementation is trivial.

However, the cost for widget developers to have to code multiple times  
for different UAs - and the opportunity cost to users and UAs where  
developers simply don't bother and end up sticking to developing for a  
single UA - is far greater.

The only debate is whether to standardize the existing practice (Apple/ 
Nokia/Opera method signatures) or attempt to harmonise with future  
practice (use Web Storage method signatures).

S

On 6 Apr 2009, at 14:45, Anne van Kesteren wrote:

> On Mon, 06 Apr 2009 15:28:47 +0200, Scott Wilson <scott.bradley.wilson@gmail.com 
> > wrote:
>> A consistent preferences interface is crucial for widget
>> interoperability; most of the widget platforms surveyed in the
>> Landscape document have a Preferences API - and have been pretty
>> consistent in how they've designed it. Its not exactly radical
>> standardisation practice to take 5 existing implementations and
>> harmonize them in a standard - in fact, not doing so is downright  
>> odd!
>
> Why would you standardize on a storage API, but not on a markup  
> language, markup language API, styling language, styling language  
> API, scripting language, etc.? It doesn't make a whole lot of sense  
> to me. Especially if it leads to user agents having to support two  
> storage mechanisms for widgets if they happen to have one already.
>
>
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/