W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] What does it mean to have an unavailable API

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Tue, 2 Jun 2009 16:41:04 +0100
Cc: Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>
Message-Id: <FE0BFF92-0A88-4FBF-AF54-2AE657ADDC74@gmail.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.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.


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

Received on Tuesday, 2 June 2009 15:41:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC