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

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.

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