RE: First brick in Policy Framework: Features and Capabilites?

I'm bumping this mail as I agree it is a good way to lay the first brick
for this stuff.

I agree that features and capabilities is the first step and that even
this step is not trivial.

Recording my thoughts against the currently available Contacts API [1] I
would like to propose the following two features be defined and
applicable to the current Contact API methods:

contacts.read
	-> Contacts.find()

contacts.write
	-> Contact.commit()
	-> ContactResult.remove()

The use of these methods requires feature opt-in from the user and/or
from any other suitable pre-defined security relationship with a user
(e.g. via a policy in a Widgets Framework).

All other properties and methods of the Contacts API not included above
are not subject to any feature opt-in process.

If we proceed with this exercise perhaps it should be in a seperate
document that collects all the features and capabilities together, much
like BONDI does [2]. 

Any other thoughts?

Kind Regards,

Richard

[1] http://dev.w3.org/2009/dap/contacts/

[2] http://bondidev.omtp.org/1.1/CR/apis/apifeatures.html



> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of 
> Dominique Hazael-Massieux
> Sent: 19 November 2009 09:34
> To: public-device-apis
> Subject: First brick in Policy Framework: Features and Capabilites?
> 
> Hi,
> 
> Based on my understanding of the discussions at the F2F, 
> there are two main pieces that people would like to see 
> coming from our work on the policy framework for Device APIs:
> * a way to identify features and capabilities of Device APIs 
> * a way to express restrictions of access to these in a 
> format that allows to interchange policies across browsers, 
> devices and policies providers
> 
> I think it is still controversial or unclear whether we can 
> usefully work on the latter - in particular, it's not clear 
> to me that we have heard many browsers say they want to 
> integrate such a policy layer in their implementations.
> 
> But there seems to be rough consensus on the usefulness of 
> the former, and there is already a fairly clear use case for 
> it - the <feature> element in Widgets P&C.
> Moreover, I could see the definitions of these features and 
> capabilities being useful even in browsers, where a Web app 
> could declare the APIs/features it require, and the browser 
> would use that declaration to inform the user and restrict 
> the available APIs to the ones in the declaration.
> As we have already alluded to during the F2F, I think 
> defining the semantics of features and capabilities is also 
> likely not to be a trivial exercice.
> 
> As a result, I think a good first step for our policy work 
> would be the definitions of features and capabilities. 
> 
> In practice, this would mean a document that defines what 
> features and capabilities are with non-normative examples of 
> how they can be used, define the semantics of the 
> capabilities required by the existing APIs (e.g. 
> Geolocation), as well as the APIs we are working on and the 
> APIs we are planning to work on. 
> I think ideally, features would be either described in each 
> API spec, or automatically derivable from their WebIDLs; but 
> before we know if that's indeed the best approach, it would 
> probably be useful to describe the features of an existing 
> API (and I think Geolocation might be a good target for that 
> exercice).
> 
> Thoughts?
> 
> Dom
> 
> 
> 
>

Received on Friday, 11 December 2009 16:48:51 UTC