W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Wed, 4 Feb 2009 09:26:48 +0000
Message-Id: <BDA3292F-5CE1-4C70-91C1-1888569EA03B@gmail.com>
To: public-webapps@w3.org

This is a pretty radical change; I can certainly see the logic of it  
in terms of reducing spec overlap. However, it does presume that  
semantically a widget preference is the same as client-side storage.  
In our implementation, storage is definitely server-side, so this  
mechanism would not really work for us.

It would be pretty trivial for an implementation to map widget API  
calls onto LocalStorage calls where this is the desired  
implementation; perhaps it would offer more flexibility to instead  
define Widget API calls for preferences that follow the same  
conventions as the HTML 5 storage API, but let implementations decide  
whether to delegate the implementation of those interfaces to the HTML  
processor (e.g. WebKit) or instead implement using a dedicated storage  

For example, the Widget object could expose a method for returning a  
"preferences" object which implements the HTML 5 Storage interface. In  
most cases this would simply return the page's "localStorage" element;  
however, the Widget object can instead implement this directly with  
its own Storage if desired.


On 3 Feb 2009, at 11:19, <ivan.demarino@orange-ftgroup.com> <ivan.demarino@orange-ftgroup.com 
 > wrote:

> Hello.
> After some emails with Marcos Caceres we reached the conclusion that
> part of the Specs of Widget APIs
> (http://dev.w3.org/2006/waf/widgets-api/) overlaps/clashes with the
> HTML5 standard draft about Key/Value Pairs Storage
> (http://www.whatwg.org/specs/web-apps/current-work/#structured-client-si
> de-storage).
> Our suggestion is that we should go with the HTML5 standard, removing
> those apis the Widget API Specs, because:
> 1) Most probably it will be supported from every browser soon anyway
> 2) There are Open Source browsers, like WebKit, were it's already
> finding it's space (take a look to the WebKit source code)
> 3) It will allow developer to learn less apis for the same purpose
> 4) They do the same thing but...
> 5) The HTML5 draft already provides APIs for "enumeration", "cleaning"
> and "iteration"
> 6) The Widget object will become more coherent, focusing on things  
> like
> "widget status" and "widget informations"
> 7) The OMTP BONDI initiative itself avoided to go into the "Persistent
> Storage" aspect, because of the presence of Google (with Google Gears)
> and HTML5 Proposal, as you can see from the "BONDI Interfaces Specs"  
> at
> http://www.omtp.org/Bondi/PublicDraft.aspx.
> Please, let me know what you think.
> Best Regards
> ---
> Ivan De Marino
> Orange Labs
> Mobile and Web Software Engineer, R&D UK
> tel. +44 20 8849 5806
> mob. +44 7515 955 861
> mob. +44 7974 156 216
> ivan.demarino@orange-ftgroup.com
Received on Wednesday, 4 February 2009 09:29:38 UTC

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