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

Defining equivalent methods to HTML 5 Storage - rather than mandating  
the same implementation -  seems like a reasonable compromise.

It would enable us to provide a consistent model for developers, while  
at the same time making it more obvious how to migrate widgets and  
authoring tools based on existing widget APIs, i.e.:

http://www.w3.org/TR/widgets-land/#apis

S

On 13 Feb 2009, at 16:54, <ivan.demarino@orange-ftgroup.com> <ivan.demarino@orange-ftgroup.com 
 > wrote:

>
> Hello.
>
> I'm trying to "stress" a bit the current implementation of  
> "preferences
> storage", comparing it to the LocalStorage.
> I see that a "preferences" array was introduced, but this araise  
> another
> problem.
> A "Javascript Array" it's NOT a map of "key/value" pairs. This means
> that the preferences will have to hold only the "values".
> This looks a bit "incoeherent" with the idea of having preferences
> stored as "key/value" pairs. Doesn't it?
>
> 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").
>
> What do 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
>
>
> 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: public-webapps-request@w3.org
> [mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking
> Sent: 12 February 2009 19:20
> To: timeless@gmail.com
> Cc: Scott Wilson; public-webapps@w3.org; Ian Hickson
> Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
> Storage
>
>
> timeless wrote:
>> I think the problem here is that there's too much syntactic sugar in
>> sessionStorage/localStorage (this is more feedback to HTML5 or  
>> WebIDL,
>
>> and maybe Hixie or others could help to address it).
>>
>> I can easily replace the object (window.sessionStorage={})
>
> The sessionStorage property is readonly so that won't work.
>
>> but I
>> can't be told when my sessionStorage is decorated by a new property,
>> because that's not something which is available to JS (gecko has
>> __noSuchMethod__, but there's no watch(sessionStorage, "*",  
>> feedback).
>>
>> If there was a way for js objects to be told about property writes
>> then for the most part, they could replace a host's
>> sessionStorage/localStorage with their own object and do what they
>> need.
>>
>> Today, if the HTML5 sessionStorage/localStorage objects relied on
>> (sugar-free) methods only, they wouldn't have a problem. -- No, I'm
>> not advocating this.
>
> Things like watch points aren't really defined if they should work  
> when
> it comes to host objects I think. And if we used an API like
> setProperty/getProperty they certainly would not work.
>
> So I don't think the problem here is with the specific API  
> localStorage
> uses either. But rather with the fact that Scott is trying to deploy a
> widget implementation in an environment where he is restricted about
> what the APIs he is implemented are called.
>
> I think in this instance though the problem can be worked around by
> adding event listeners to the Document listening for 'storage' events.
> That can be used to then save the data server-side.
>
> / Jonas
>
>