RE: Updated Features draft

+1 for dropping the Features/Capabilities distinction according to Dom's proposal.

Claes

> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Dominique Hazael-Massieux
> Sent: den 14 september 2010 10:03
> To: Frederick.Hirsch@nokia.com
> Cc: public-device-apis@w3.org
> Subject: Re: Updated Features draft
> 
> Hi Frederick,
> 
> Any feedback on my proposal/questions below?
> 
> Dom
> 
> Le jeudi 02 septembre 2010 à 09:50 +0200, Dominique Hazael-Massieux a
> écrit :
> > 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 16:11:12 UTC