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

Jonas,

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.

S

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

> 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.demarino@orange-ftgroup.com
> <ivan.demarino@orange-ftgroup.com> wrote:
>> Hello.
>> Just to clearify: I never spoke about implementations.
>> I always spoke about interfaces to define in this Standard:  
>> adoption and
>> 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 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();
>>> ...
>>> }
>>>
>>> This ensures "enumeration" and some "utility" methods that can  
>>> become
>>> handy (like a "clear" and a "count").
>>
>> 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
>>
>>
>> This e-mail, and any files transmitted with it, is intended only  
>> for the
>> 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
>> 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
>> all copies of this e-mail.  Thank you.
>>
>> France Telecom R&D UK Ltd is a company registered in England and  
>> Wales
>> with company number 4193379. Our registered office is Minerva House,
>> Montague Close, London, SE1 9BB.
>>
>> -----Original Message-----
>> From: Jonas Sicking [mailto:jonas@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.landspurg@gmail.com> wrote:
>>>   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.
>>
>> Hmm.. i'm a bit confused. My proposal was to use a server side  
>> backend
>> for the .localStorage API. This would mean that there is no need to
>> introduce a new API.
>>
>> 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
>> API. So that does not seem like a good solution.
>>
>> However it seems possible to use other solutions to implement a  
>> server
>> side backend for localStorage by using the callbacks defined in the
>> HTML5 spec.
>>
>> / Jonas
>>