- From: Rich Tibbett <rich.tibbett@gmail.com>
- Date: Fri, 18 Jun 2010 17:17:38 +0100
- To: Frederick.Hirsch@nokia.com
- Cc: public-device-apis@w3.org
- Message-ID: <AANLkTikF337iWzTBLoxJFR60AyeP8y41CzyOZ96tQZPI@mail.gmail.com>
Hi Frederick, I sent an email to the list in December defining how I saw capabilities mapping to the Contacts API. The API methods remain unchanged (except that commit() is now called save()). http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0195.html regards, Richard On Wed, Jun 16, 2010 at 2:39 PM, <Frederick.Hirsch@nokia.com> wrote: > Some time ago Daniel provided an overview of device capabilities [1] and a > pointer to BONDI definitions [2]. > > It seems, however, that these definitions may not map directly to the DAP > API definitions, especially as the DAP interfaces evolve. > > Taking Contacts, as an example, the BONDI definitions include: > > pim.contact.read Read the contacts stored in the terminal pim.contact.writeWrites contacts to be stored in the terminal > > > However our current contacts editors draft [3] has find, create, clone, > save, remove as methods, as well as more granular access control > opportunities on the ContactProperties interface. > > It seems that this kind of issue might occur with a number of > specifications. > > In this case it seems we have capabilities for creation, deletion, and > update as well as find (and some possible granularity on find). > > If capabilities were marked in the Web IDL itself it would aid in > automatically generating, using and testing capabilities - is this an > approach worth considering? > > It appears we will need API specific definitions of capabilities. > > regards, Frederick > > Frederick Hirsch > Nokia > > [1] > http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0142.html > > [2] http://bondi.omtp.org/1.1/apis/devcaps.html > > [3] http://dev.w3.org/2009/dap/contacts/ > >
Received on Friday, 18 June 2010 16:18:31 UTC