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
>