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

Making a static declaration of a <feature> to indicate to the UA which  
APIs to make available to a widget is already used in existing widget  
and gadget implementations; requestFeature() isn't.

For example, here is the definition used by Google, and implemented in  
Shindig:

> Gadget Features. A list of all gadget features that are either  
> required for the gadget to operate, or may optionally be utilized if  
> available. Gadget features are the primary extensibility mechanism  
> employed by gadgets. They often direct a gadget server to make new  
> JavaScript APIs available to rendering code, but may also manipulate  
> the gadget's contents, for example to add extended syntax. Examples  
> of gadget features include OpenSocial (provides gadgets with a rich  
> set of social APIs), dynamic-height (enables gadgets to resize  
> themselves to an appropriate height), and tabs (a UI library  
> facilitating tabular navigation).


We use a similar definition in relation to Widgets.

We specifically use <feature> for indicating to the UA to make shared  
state handling available and active, and plan to use it to indicate  
whether we should provide oAuth capability for a given widget. If this  
element were not in the specification, we'd have to create an  
extension that did the same thing anyway.

The BONDI requirement is to dynamically add APIs once a Widget has  
already been instantiated. This may not suit some implementations. For  
example, our implementation has no way of dynamically injecting APIs  
into a Widget instance while it is already running; if BONDI wishes to  
require this capability of implementations this is not in the scope  
for Widgets. Currently the Widget A&E spec makes no claim that Widget  
UAs must be able to dynamically load additional functionality on  
request.

If a given UA implemented BONDI and a Widget chooses to use its  
requestFeature() method, then in that instance for that Widget,  
<feature> may be redundant. However, for Widgets not created  
specifically for BONDI that are used in a BONDI UA, this is not an  
issue; <feature> works fine and is not affected by the existance of  
the BONDI getFeature() extension. Also for UAs that support Widgets  
but not BONDI extensions, it is not an issue that the extension exists.

Personally I don't really see a good UC for requestFeature(), but its  
proposed as a BONDI extension and not a W3C Widgets A&E feature, so I  
support Marcos' position that we let it be.

S

On 9 Jun 2009, at 10:58, Anne van Kesteren wrote:

> On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres  
> <marcosc@opera.com> wrote:
>> Like I said, as far as WebApps is concerned requestFeature() does not
>> exists. What I meant was the requestFeature() undermines <feature>
>> without addressing the security issues.
>
> I'm getting more and more confused. You claim you do not understand  
> requestFeature(). You claim requestFeature() makes <feature>  
> useless. You claim requestFeature() is irrelevant with respect to  
> <feature>. And now you claim requestFeature() is less secure than  
> <feature>.
>
> I do not get at all the feeling that this feature is ready for  
> standardization.
>
>
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/
>