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

Hi Ivan,

No worries!

I think what I'd propose would be to replace this in the current  
Widget API spec:

   attribute Array preferences;
   DOMString setPreference(in DOMString name, in DOMString value);
   void getPreference(in DOMString name);

With this:

   attribute Storage preferences;

Then in our implementation we'd return our own "widgetStorage" object  
for the preferences attribute rather than localStorage, so we'd have  
to implement the Storage interface in "widgetStorage", including  
enumeration (etc). Its a bit of a shift, but I think we can make it  
work. The main thing bothering me at the moment is whether we can  
still support callbacks with this approach.

S

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

> Hi Scott,
>
> I see what you mean. My mistake: I completelly missed that part of the
> email.
> As for your implementation, of course this could be a solution that  
> will
> accommodate things.
>
> Still, there is an important set of functionalities that the HTML5  
> specs
> offer that is missed by the Widget.set/getPref APIs: enumeration and
> clearing.
> How do you plan to work around this in your implementation?
>
> In our case we are thinking to do something "similar": keep Html5
> storage implementation, making it available, BUT, with some injected
> Javascript, create also the Widget apis.
> Our current implementation will work as "back end".
>
> 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: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: 11 February 2009 12:26
> To: DE MARINO Ivan RD-ILAB-LON
> Cc: jonas@sicking.cc; public-webapps@w3.org; UDDIN Rafel RD-ILAB-LON;
> TIBBETT Richard RD-ILAB-LON
> Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
> Storage
>
> Hi Ivan,
>
> I wasn't rejecting HTML5 Storage at all, in fact you can see in para  
> 3 I
> suggested a way of offering the HTML 5 Storage API  to widgets in a  
> way
> that is far less "close" to final implementation than requiring the  
> use
> of the localStorage implementation of the HTML 5 Storage Interface.
>
> S
>
> On 11 Feb 2009, at 10:53, <ivan.demarino@orange-ftgroup.com>
> <ivan.demarino@orange-ftgroup.com  > wrote:
>
>> Hello.
>>
>> This sounds to me a bit too much "personal" as motivation.
>> The fact that you implement the APIs as server side, because your
>> widget live in a "Local Webserver" doesn't justify the reject of  
>> HTML5
>
>> Storage as alternative to set/getPref APIs.
>>
>> By the way, HTML5 Local Storage Key/Value Pairs is all "client side":
>> there is nothing that involve any server side.
>> And this should be the same for Get/SetPreferences in Widgets,
>> otherwise the spec will be too "close" and too "focused" on the final
>> implementation.
>>
>> 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 Scott Wilson
>> Sent: 11 February 2009 09:54
>> To: Jonas Sicking
>> Cc: public-webapps@w3.org
>> Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
>> Storage
>>
>> Hi Jonas,
>>
>> We run the widgets from a server, which a web application renders  
>> into
>> the browser window using iFrames (a typical "web widget"
>> architecture). Each widget in its iFrame calls the Widget API  
>> getPref/
>> setPref methods, which are implemented in a locally injected JS
>> library.
>> This library implements the get/setPref methods as AJAX requests
>> back to
>> the server.
>>
>> If the widget used the LocalStorage interface, the server would not  
>> be
>> engaged in the storage process, as localStorage is implemented by the
>> browser itself. We might then run into issues where the same widget
>> was
>> instantiated for different users in different contexts - currently we
>> issue an opaque identifier to each running widget instance that
>> enables
>> the server to keep the user preferences separate - though perhaps  
>> this
>> could be picked up by the localStorage implementation if
>> it used the querystring as part of calculating the storage scope.
>> We'd still get an issue, however, of users losing all their widget
>> preferences if they accessed them from a different device, or a
>> different browser on the same device, which would be annoying.
>>
>> (Admittedly this is not an issue for single-user environments...)
>>
>> However we could get around this by having the Widget object return a
>> handle for an object that implemented the HTML 5 Storage interface -
>> in
>> our implementation this would then be an object we define in our
>> injected JS library (using AJAX once again), while in other
>> implementations this could either be the localStorage instance, or a
>> facade that maps the calls onto another storage method (e.g. Apple
>> CoreStorage).
>>
>> It may also be worth exploring having a separate mechanism for
>> handling
>> access to arbitrary container-managed attributes (for example, the
>> current user's display name, role, or other profile
>> information) in a similar fashion; currently we use preferences to
>> handle these as well.
>>
>> (NB: "web widgets" are not explicitly within the scope of the W3C
>> Widgets spec, but  I think it would be good to provide solutions  
>> which
>> don't rule them out either.)
>>
>> S
>>
>>
>> On 11 Feb 2009, at 02:54, Jonas Sicking wrote:
>>
>>> On Wed, Feb 4, 2009 at 1:26 AM, Scott Wilson
>>> <scott.bradley.wilson@gmail.com> wrote:
>>>>
>>>> This is a pretty radical change; I can certainly see the logic of  
>>>> it
>>>> in terms of reducing spec overlap. However, it does presume that
>>>> semantically a widget preference is the same as client-side  
>>>> storage.
>>>> In our implementation, storage is definitely server-side, so this
>>>> mechanism would not really work for us.
>>>
>>> I'm not sure I understand the difference. Can you describe why your
>>> implementation wouldn't be able to store the HTML5 API server-side?
>>> Are there any changes we could do to the HTML5 API that would  
>>> allow a
>>> server-side back-end?
>>>
>>> / Jonas
>>
>