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.demar...@orange-ftgroup.com> <ivan.demar...@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.demar...@orange-ftgroup.com
