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

   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.


On Fri, Feb 13, 2009 at 6:37 PM, Scott Wilson <
scott.bradley.wilson@gmail.com> wrote:

> 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
>>
>>
>>
>


-- 
Get the ALL NEW Webwag Mobile - http://webwag.com/mobile
Thomas Landspurg -  Webwag  CTO and Co-founder
http://www.webwag.com Tel: +33 6 32 29 42 16