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

[Scott Wilson]

Hi Ivan,




S

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. On 11 Feb 2009, at 10:53, <ivan.demar...@orange-ftgroup.com> <ivan.demar...@orange-ftgroup.com > wrote:

Hello.

This sounds to me a bit too much "personal" as motivation.

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.

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.demar...@orange-ftgroup.com



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

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-requ...@w3.org
[mailto:public-webapps-requ...@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/

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

instantiated for different users in different contexts - currently we

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

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


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:

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 And this should be the same for Get/SetPreferences in Widgets, otherwise This e-mail, and any files transmitted with it, is intended only for the this e-mail. If an addressing or transmission error has misdirected this setPref methods, which are implemented in a locally injected JS library. This library implements the get/setPref methods as AJAX requests back to browser itself. We might then run into issues where the same widget was issue an opaque identifier to each running widget instance that enables handle for an object that implemented the HTML 5 Storage interface - in It may also be worth exploring having a separate mechanism for handling

On Wed, Feb 4, 2009 at 1:26 AM, Scott Wilson
<scott.bradley.wil...@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

smime.p7s
Description: S/MIME cryptographic signature