- From: Samuel Ortiz <sameo@linux.intel.com>
- Date: Wed, 20 Feb 2013 10:38:32 +0100
- To: "Yriarte, Luc" <luc.yriarte@intel.com>
- Cc: "public-nfc@w3.org" <public-nfc@w3.org>
Hi Luc, On Wed, Feb 20, 2013 at 09:31:38AM +0000, Yriarte, Luc wrote: > Hi Samuel, > > > > I think this would be a very convenient API. It could also apply to the > > Tag interface when we want to write a Handover NDEF there (Handover > > select for static handover). > > Okay so that would mean writing handover select information about a specific device on a NFC tag. Should the API take some device-related parameter then, like a pin code or a mac address ? > Yes. A BD address would be sufficient, no need for a pin code. > > Also, in order to avoid offering the same feature through several API > > paths, we should forbid to build Handover NDEF if we offer this > > handover specific API. Otherwise apps would be able to use both the > > Handover creation + nfcpeer.sendndef API and the nfcpeer.startHandover > > one, for exactly the same results. I think this is a confusion we > > should avoid. > > This one will be pretty straightforward. Currently the only NDEF record types we support are "text" and "uri", with "media" coming next. Even if the underlying Neard Handover API is based on specific NDEF record types, we are not required to expose it this way. Conceptually we can separate Handover from NDEF record types, and design a specific set of APIs. > Sounds good then. We have to keep that in mind and not add handover type records to the API further down the road. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/
Received on Wednesday, 20 February 2013 09:39:09 UTC