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: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Wed, 11 Feb 2009 12:26:20 +0000
Cc: <jonas@sicking.cc>, <public-webapps@w3.org>, <rafel.uddin@orange-ftgroup.com>, <richard.tibbett@orange-ftgroup.com>
Message-Id: <8123E42E-5285-4BBC-9763-00904B90DF01@gmail.com>
To: <ivan.demarino@orange-ftgroup.com> <ivan.demarino@orange-ftgroup.com>
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  


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

Received on Wednesday, 11 February 2009 12:26:59 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC