Re: [widgets] Purpose and utility of <feature> unclear

On Jun 1, 2009, at 16:44, Marcos Caceres wrote:

> On Mon, Jun 1, 2009 at 1:25 PM, Henri Sivonen <hsivonen@iki.fi> wrote:

>>> Using a feature element denotes that, at runtime, a widget may  
>>> attempt to
>>> access the feature identified by the feature element's name  
>>> attribute.
>>
>> Why is this useful to denote? What happens if a widget doesn't  
>> denote that
>> it'll attempt to use a feature but does so anyway?
>
> Then it will fail as the feature will not have loaded. Feature loading
> has to be explicit (unless the feature is enabled by default, as might
> become the case eventually with, say, Geo-location).

In general, this policy seems alien to browser technologies.

>>> Using a feature element denotes that, at runtime, a widget may  
>>> attempt to
>>> access the feature identified by the feature element's name  
>>> attribute.
>>
>>
>> Why aren't all the implemented features simply available like in a  
>> Web
>> browser engine?
>
> Feature is for proprietary extensions: BONDI makes extensive use of
> this element. There are also security considerations: Members of the
> WG have asked why would you want the contacts API, for example, to be
> enabled by default? if you don't enable it and make it available, then
> malicious injected code cannot access those APIs. In widgets, the
> security model that we are discussing is one where APIs are made
> available on request only... or till implementers consider them benign
> enough to allow them in the wild (e.g., XHR).

I think it would be preferable to design APIs in such a way that  
security/privacy aspects of the API are Web-ready, i.e. the same API  
could be exposed to Web content. (I consider the design of the  
Geolocation API and it's authorization UI in Firefox Web-ready in this  
sense.)

Failing that, I now see the point of the security aspect of the  
<feature> design. However, for that case, I think the default policy  
for upcoming features of the platform (feature unavailable unless part  
of Widgets 1.0 Family) is backwards if the widget platform is viewed  
as a an extension to the browser platform that keeps up with the  
evolution of the browser platform as opposed to being a one-time fork  
of the browser platform.

It seems to me it would be better to allow features with a Web-ready  
security model to be made available by default and require widget- 
oriented feature specs that lack a Web-exposable security model opt in  
to the <feature> security model.

>>> A user agent can expose a feature through, for example, an API, in  
>>> which
>>> case a user agents that supports the [Widgets-APIs] specification  
>>> can allow
>>> authors to check if a feature loaded via the hasFeature() method.
>>
>> Wouldn't this have all the same problems that DOM hasFeature() has  
>> had
>> previously
>
> Excuse my ignorance, but I don't know what those problems are. Can you
> please give us a pointer?

Implementations have an incentive to claim to have a feature when they  
have only partial support. OTOH, when implementors try to do the Right  
Thing and resist the temptation, partial implementations will report  
false even though the script in question could have worked with only  
the part of the implementation that exists. Also, actual feature  
implementation status and what hasFeature reports may be out of sync  
just by omission.

javascript:alert(document.implementation.hasFeature("Selectors-API",  
"1.0")), for example, says false to me on Firefox trunk.

>> and the problems that have been pointed out as reasons not to
>> have feature detection at-rules in CSS? Namely, that  
>> implementations have
>> the incentive to claim that they have a feature as soon as they  
>> have a
>> partial buggy implementation.
>
> Ok, I see; that is bad. Can you recommend what we should do instead?

Scripts should try to use a given API and whine to the user or perform  
workarounds if the API is missing.

>>> A boolean attribute that indicates whether or not this feature  
>>> must be
>>> available to the widget at runtime. In other words, the required  
>>> attribute
>>> denotes that a feature is absolutely needed by the widget to  
>>> function
>>> correctly, and without the availability of this feature the widget  
>>> serves no
>>> useful purpose or won't execute properly.
>>
>> What's a widget engine expected to do when an unrecognized feature is
>> declared as required?
>
> Ah, good point! I had not completely specified that in the processing
> part of the spec. It now reads:
>
> "If feature-name is not a valid URI, and required-feature is true,
> then treat this widget as an invalid widget package.
>
> If feature-name is not supported by the user agent, and
> required-feature is true, then treat this widget as an invalid widget
> package.
>
> If feature-name is not supported by the user agent, and
> required-feature is false, then this element, its attributes, and its
> children are in error and must be ignored. Stop processing this
> element and proceed to the next element in the elements list."

Thanks. That makes it clearer what <feature> is about.

>> If there are two such engines, how do they converge on the same  
>> feature name
>> string of the specifiers of the feature itself just meant it to be  
>> available
>> to Web content unconditionally and didn't bother to mint a widget  
>> feature
>> string?
>
> Like I said, feature was originally intended to request access to
> proprietary features designed for widgets (namely BONDI). If the API
> just becomes available in the browser, then no feature string is
> needed. But yes, we have a potential problem here until we settle on
> the security model.


It seems to me this issue is solved by making only widget-oriented  
(BONDI) features participate in the <feature> model and making Web- 
oriented features (like Geolocation) not participate (i.e. work like  
they work in a browser).

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 1 June 2009 14:41:22 UTC