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

[Scott Wilson]

Jonas,






S

On 17 Feb 2009, at 07:46, Jonas Sicking wrote:

One level of indirection is a very small price to pay for much more implementation flexibility. It won't hurt developers (the methods are equivalent) and it decouples the specifications enough to support different deployment models. What (I think - correct me if I'm wrong) you've been proposing is to essentially mandate that Widgets can only work if the environment implements HTML 5; now I like HTML 5, and I think LocalStorage is great, but I don't think it should be _necessary_ to bind Widgets to HTML 5 in order for them to work - after all, using the existing draft API (based on the Apple, Nokia, and Opera APIs) they work already! So why add the restriction? Especially as what Ivan is proposing is to remove any inconsistency between the Widget Preferences and HTML 5 Storage interfaces.

Hi Ivan,

I'm still unclear on what advantage your proposal has over simply
using the HTML5 API? (backed by an implementation that uses
server-side storage if so desired)

/ Jonas

On 2/16/09, ivan.demar...@orange-ftgroup.com
<ivan.demar...@orange-ftgroup.com> wrote:

Hello.
Just to clearify: I never spoke about implementations.

implementation is a "personal" step.
Neither the usage of a server side component nor a direct client side
javascript extension was in my target.

If this matter was already clear, then ignore this email ;)

I always spoke about interfaces to define in this Standard: adoption and

...
I would propose to introduce the same kind of methods available for
HTML5 LocalStorage. Not necessarelly the same signatures, but

equivalent methods.

This means to modify slightly the "widget" object introducing stuff
like:
class widget {
...
        long preferencesCount();
        
        string getPreferenceKey(long index) throws

DomException.INDEX_SIZE_ERR;

        
        string getPreference(string key);
        
        void setPreference(string key, string value) throws

DomException.QUOTA_EXCEEDED_ERR;

        
        void removePreference(String key);
        
        void preferencesClear();
...
}


handy (like a "clear" and a "count").

This ensures "enumeration" and some "utility" methods that can become

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



use of the person/s or entity to whom it is addressed. If you are not
the intended recipient (or authorised to receive information for the

all copies of this e-mail.  Thank you.


with company number 4193379. Our registered office is Minerva House,
Montague Close, London, SE1 9BB.

-----Original Message-----
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: 13 February 2009 23:44
To: Thomas Landspurg
Cc: Scott Wilson; DE MARINO Ivan RD-ILAB-LON; public-webapps@w3.org
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage

On Fri, Feb 13, 2009 at 9:47 AM, Thomas Landspurg
<thomas.landsp...@gmail.com> wrote:

This e-mail, and any files transmitted with it, is intended only for the intended recipient) you must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and delete France Telecom R&D UK Ltd is a company registered in England and Wales

  Hello,

 I am a little bit late in the debate, but I agree with scott
proposal and arguments. Ideally the widget itself shoud not be aware
of HTML5 storage implementation, even if the widget storage API use
the same signature . And mostly because of the same need: some
architecture would require a server side implementation of the
settings instead of a client side, especially if you want to provide

the same account on different platforms.


for the .localStorage API. This would mean that there is no need to
introduce a new API.


API. So that does not seem like a good solution.


side backend for localStorage by using the callbacks defined in the
HTML5 spec.

/ Jonas

Hmm.. i'm a bit confused. My proposal was to use a server side backend From my understanding of the original issue that was brought up in this thread, using a separate API rather than .localStorage would only be a short term solution, until browsers start natively supporting the widget However it seems possible to use other solutions to implement a server

smime.p7s
Description: S/MIME cryptographic signature