- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Wed, 4 Feb 2009 09:26:48 +0000
- 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 mechanism. 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. S 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