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.wil...@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.demar...@orange-ftgroup.com
ivan.demar...@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, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@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 RD 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 Jonas Sicking
Sent: 12 February 2009 19:20
To: timel...@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
Re: [widgets] OAuth and openID
But one of the major issue with oauth is the fact that is quite impossible to use it outside the browser model. For mobile application, or application without browser, the model is to use your PC to log in, to get a token, and then to put this token in your device. The OAuth rationale is that the user will trust more the browser provider than the application provider. The actual situation, is that it's then impossible to provide a good user experience on constrained device, and I've seen application embeeding some browser just to solve this OAuth issue. It's even worst for non brower based device. As we are moving to the internet of connected device, I personnaly thing that widget are a good way to manage this iternet of connected device, but we still have an issue with authentification which is not yet fully solved with OAuth. On Mon, Feb 23, 2009 at 3:31 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: I agree that postponing any detailed work may be the most pragmatic answer, however oAuth is actually a very important technology for Widgets. oAuth enables a user of an application such as a widget to link that application to an external service, without the application storing, or having access to, any user credentials. For example, using oAuth, a Photo Widget could get access to a user's Flickr account, without the Photo Widget storing the username and credentials of the user, just an authorization token that cannot be reused for any other user or service. To set up the token, the first time the Photo Widget is installed, the user is prompted to go to Flickr, log in there, and agree to grant the widget access to the service. Currently very many widgets store user's account details in widget preferences as this is the only means of user access they have that doesn't involve the user constantly re-entering account details to get at basic functionality. In some environments this may not be a significant risk, depending on how preferences are stored and accessed; however in many cases the fact that a widget can impersonate the user (logging on as the user, rather than with a token) causes issues for trust and auditing. Because many widgets are small local applications offered for remote services that use different user accounts, oAuth is a very important and relevant technology. Which is why, for example, it has been a major task in the oAuth and OpenSocial/Gadgets community to integrate the technology. ((Note also that last I heard oAuth was going to IETF for standardisation)) S On 23 Feb 2009, at 11:02, Thomas Roessler wrote: On 23 Feb 2009, at 05:15, Jon Ferraiolo wrote: OAuth is a technology that authorizes someone to do something. For example, an OAuth server might authorize you to cast a vote in an election. Regarding authorization, in the most common case of W3C Widgets, you would most likely use something like an OMTP/BONDI policy file or some sort of platform-specific (maybe implicit) policy to control authorization instead of OAuth. My thinking is that you can ignore OAuth for now. I think you're conflating policy and protocol here -- OAuth is a way to share an authorization token (and really not much more); it doesn't tell you how to write your authorization policies. If I were on the committee, I would push to finish Widgets 1.0 as quickly as possible, and then put OpenID and OAuth on the list for things to consider for Widgets 1.1. +1 OAuth seems most relevant to XMLHttpRequest level 2, and much less relevant to the widget specs. -- 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
Re: [Widgets] Widget Gallery RSS like sharing format
Good suggestion. I think RSS/Atom is well adapted for new widgets publication. I think that keeping the platform attribute is interesting, because we - as many - we will have to support different format for some time. On Wed, Mar 11, 2009 at 2:14 PM, SUZANNE Benoit RD-SIRP-ISS benoit.suza...@orange-ftgroup.com wrote: All, Based on our last F2F, we have talked about an RSS like file format that would standardise the widget list for various needs. I do not consider the following as a formal format proposition but as an input to open the discussion as it should probably be written in atom instead of RSS. So here we go, here is an example of the xml format: *rss* version=2.0 xmlns:dc=http://purl.org/dc/elements/1.1/; xmlns:atom=http://www.w3.org/2005/Atom; *channel* *title*Djinngo Widget Catalog on vista/*title* *atom*:link rel=self href=http://example.com/gallery// *link*http://example.com/gallery//link *description*![CDATA[]]/*description* *language*en/*language* *item* *id*3_LiveRadio/*id* *title*![CDATA[Orange LiveRadio]]/*title* *platform*vista/*platform* *category*4/*category* *version*1.4.0/*version* *link*http://example.com/gallery/#widget=3_LiveRadio/*link* *guid* isPermaLink=true http://example.com/gallery/#widget=3_LiveRadio/http://example.com/gallery/#widget=3_LiveRadio%3C/ *guid* *language*14/*language* *description*![CDATA[Orange LiveRadio gadget]]/*description* *screenshot*http:// example.com/GadgetFactory/widgets/screenshots/liveradio-fr.jpg/* screenshot* *author_name*![CDATA[Orange]]/*author_name* *pubDate*![CDATA[Fri, 12 Jan 2007 00:00:00 +0100]]/*pubDate* *downloads*0/*downloads* *download_url*http://download.example.com/Orange-LiveRadio-FR-v2.gadget /*download_url* *rating*0.0/*rating* /*item* *item* *id*3_OrangeSport/*id* *title*![CDATA[Orange Sport]]/*title* *platform*vista/*platform* *category*2/*category* *version*1.3.0/*version* *link*http:// example.com/gallery/#widget=3_OrangeSport/*link* *guid* isPermaLink=true http://example.com/gallery/#widget=3_OrangeSport/guidhttp://example.com/gallery/#widget=3_OrangeSport%3C/guid%3E *language*14/language *description*![CDATA[Suivez toute l'actualité sportive en direct.]]/ *description* *screenshot*http://example.com/widgets/screenshots/sport.jpg/* screenshot* *author_name*![CDATA[Orange]]/*author_name* *pubDate*![CDATA[Tue, 20 Nov 2007 00:00:00 +0100]]/*pubDate* *downloads*0/*downloads* *download_url*http://download.example.com/Orange-Sport-FR.gadget/* download_url* *rating*0.0/*rating* /*item* ... /*channel* /*rss* The idea is to describe the following elements: *- title*: is the widget’s name - *pubDate*: is the date of the publication of the widget - *guid*: defines a unique identifier for the item *- platform*: is the widget’s platform *- category*: is the number corresponding to a category item *- version*: the widget’s version. *- link*: is the link toward the widget page on the Djinngo gallery. *-* *language*: is the number corresponding to a language, although here we should probably use the language format of the PC spec *- description*: the widget’s description. *- screenshot*: is the direct link to a screenshot of the widget. *- downloads*: the number of downloads for the widget. *- download_url*: is the direct link to download the widget. *- rating*: the rating the widget on the gallery. Best Regards, Benoit *Benoit Suzanne *Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 *benoit.suza...@orange-ftgroup.com * -- 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
