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.wil...@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 andharmonize 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/
smime.p7s
Description: S/MIME cryptographic signature
