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: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 16 Feb 2009 23:46:33 -0800
Message-ID: <63df84f0902162346v12b6fddapd4befa4725e4ea24@mail.gmail.com>
To: ivan.demarino@orange-ftgroup.com
Cc: thomas.landspurg@gmail.com, scott.bradley.wilson@gmail.com, public-webapps@w3.org
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
>
Received on Tuesday, 17 February 2009 07:47:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT