- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Tue, 2 Jun 2009 16:41:04 +0100
- To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Cc: Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>
- Message-Id: <FE0BFF92-0A88-4FBF-AF54-2AE657ADDC74@gmail.com>
Hi Marcin, Yes, on (1); the Google example I was referring to does the same. So, for example, "analytics" is the feature name, but this means the whole module, which includes a couple of JS libs and a range of functions. For hasFeature() the only UC I can see is if your Widget declares a Feature, but doesn't require it (REQUIRED=false), but can make use of it for added functionality if it is available. (Sorry Marcos, just remembered this one - don't get rid of hasFeature() yet!) I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. S On 2 Jun 2009, at 15:28, Marcin Hanclik wrote: > Hi Scott, > > In BONDI we have discussed the (has/request)Feature() for some time. > http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf > , section 4.3 > > A few points for further discussion: > 1. feature (at least in BONDI) is an abstract thing, not just one > function. So hasFeature() is simply optimized checking procedure. If > you check for a feature and discover that it is available, you may/ > should/must assume that a set of functions is available. Otherwise, > you have to check each function individually and basically you > cannot assume that if one functions is available, then the other is > as well. > > 2. requestFeature() adds dynamism to the Website content. Widgets > express their dependency statically by <feature>. > http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf > B.2 specifies more details. > > Thanks. > > Kind regards, > Marcin > > Marcin Hanclik > ACCESS Systems Germany GmbH > Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 > Mobile: +49-163-8290-646 > E-Mail: marcin.hanclik@access-company.com > > -----Original Message----- > From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org > ] On Behalf Of Scott Wilson > Sent: Tuesday, June 02, 2009 3:18 PM > To: Henri Sivonen > Cc: public-webapps > Subject: Re: [widgets] What does it mean to have an unavailable API > > I think in such a case the UA should not be expected to make frob() > available, and the Widget should not expect frob() to be present. > > For example, in the Shindig opensocial runtime, client JS is injected > based on the <require> elements of the gadget. If it isn't declared, > it isn't injected, and if you try calling those functions they just > aren't there. > > What this does make less clear for me is in W:A&E why you'd ever want > to call "hasFeature()"? > > S > > > On 2 Jun 2009, at 13:51, Henri Sivonen wrote: > >>> >>> Ok. I see what you mean. Widget.hasFeature has slightly different >>> semantics (in widgets, it means "did that feature I requested load >>> and become available?" >> >> Which brings up the issue that it's unclear what it means for an API >> to have latent support but not having been activated with <feature>. >> >> If a widget UA has an implementation for window.frob() and frob() >> requires <feature> activation, what should happen when frob() hasn't >> been activated with <feature>? Should there be no function object >> for frob()? Or should it be there but throw upon calling? Or >> something else. >> >> Please specify this. >> >> -- >> Henri Sivonen >> hsivonen@iki.fi >> http://hsivonen.iki.fi/ >> >> >> > > > ________________________________________ > > Access Systems Germany GmbH > Essener Strasse 5 | D-46047 Oberhausen > HRB 13548 Amtsgericht Duisburg > Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda > > www.access-company.com > > CONFIDENTIALITY NOTICE > This e-mail and any attachments hereto may contain information that > is privileged or confidential, and is intended for use only by the > individual or entity to which it is addressed. Any disclosure, > copying or distribution of the information by anyone else is > strictly prohibited. > If you have received this document in error, please notify us > promptly by responding to this e-mail. Thank you.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 2 June 2009 15:41:50 UTC