Re: Updated Features draft

Hi Dom

Looking at the current draft Features document I see the following definition from the BONDI contribution:

"A Feature is a set of JavaScript APIs and/or device behaviors that provide access to specified Device Capabilities. A Feature is identified uniquely by IRI, and is the unit of expression of dependencies by BONDI Web Applications."

The simplest case corresponding to this definition is to refer to an individual API and the permissions it needs.  In this case there is no need for "feature", since it corresponds 1-1 to the named API. I like simplification in general since it makes easier comprehension, testing and adoption. I didn't see an essential case for features when I put this draft together - it might be a something to consider in v2 as another layer if needed.

Thus the architecture simplifies to the following:

1. Identified APIs (or all APIs)
2. trust domains
3. capabilities allowed for each trust domain, either across all APIs or on a  per-API basis

This  corresponds to the Nokia contribution. For usability the Nokia contribution includes  defining named groups of capabilities - to ease the association with trust domains, but those are not what we are calling features.

So, I'm ok with the simplification of not referring to features and focusing on trust domains + capabilities + API naming (method + class name I assume).

I'd be interested whether Paddy and Laura agree.

It would be great in my opinion if you can take another pass.

Thanks!

regards, Frederick

Frederick Hirsch
Nokia



On Sep 2, 2010, at 3:50 AM, ext Dominique Hazael-Massieux wrote:

> Hi Frederick,
> 
> Le mercredi 25 août 2010 à 17:26 +0200, Frederick.Hirsch@nokia.com a
> écrit :
>> I added a warning to clarify that BONDI and Android material are
>> informative examples  and likely to change. I also removed the empty
>> capability sub-sections.
> 
> I see that you've brought back the Features/Capabilities distinction;
> but the features sections is entirely empty at this stage, and the
> Capabilities section makes references both to Android Capabilities and
> BONDI features.
> 
> I wonder if we shouldn't drop that distinction entirely, and simply
> talks about "permissions" or "access permissions"? In other words, it's
> not clear to me what it buys us to have this layering of
> capabilities/features when this distinction doesn't exist in browsers
> today, and when the widgets P&C spec only know about a single layer as
> well.
> 
> In terms of granularity, I think we should start from the granularity
> used by browsers today (e.g. no distinction between
> geolocation.getCurrentPosition and geolocation.watchPosition would imply
> a single permission string for geolocation) for existing APIs, and start
> from what we've described in our drafts for the new APIs.
> 
> I'm willing to take a stab at it (as per my ACTION-263), but only if
> that direction makes sense to you.
> 
> Dom
>

Received on Tuesday, 14 September 2010 22:33:08 UTC