Re: Towards a common NFC draft...

I've implemented NFC APIs for PhoneGap (Android, BlackBerry 7, BlackBerry
10, Windows Phone 8) http://github.com/don/phonegap-nfc and I'm working on
a NDEF API for Arduino https://github.com/don/Ndef.

I've read through the 2 versions of the specs listed.  Here are some notes.

==============
NdefRecord
==============

## Strings instead of Byte Arrays

I like that you're using String for record type and record id.  String
would be much more convenient for the API user. I am currently use byte
arrays since that's what Android was using.

Is there anything in the NFC specifications that would allow non-String
record type or record id? Can these be assumed to have ASC-II encoding?

## TNF

Since TNF is a 3 bit integer, should this be a Number rather than a String?

Would an Enum be better?
enum TNF { TNF_EMPTY (0x0), TNF_WELL_KNOWN (0x01), TNF_MIME_MEDIA (0x02),
TNF_ABSOLUTE_URI (0x03), TNF_EXTERNAL_TYPE (0x04), TNF_UNKNOWN (0x05),
TNF_UNCHANGED (0x06), TNF_RESERVED (0x07) }

## Binary Payloads

How is the Intel spec handling binary payloads?

## Determining Record Type

I like some of what Rob Williams Jnr (@robbieDubya) from RIM has done with
the BlackBerry 10 NdefTagReading example.

Particularly I like "record.isType(tnf, type)"
https://github.com/blackberry/BB10-WebWorks-Community-Samples/blob/master/nfc/ndefTagReading/js/blackberrynfc.ndef.js#L318

NdefRecord
    tnf - {"EMPTY", "WELL_KNOWN", ...}
    type - String
    id - String
    payload - byte[]
    boolean isType(tnf, type)

========================
NDEF Record subclasses
========================

## URIRecord

Is URIRecord handling both TNF Absolute URI (0x03) and TNF Well Known
(0x01) with RTD TEXT ("T")?
This object hides the encoding and decoding of the prefix from the user?

Would the default encoding use TNF Well Known, RTD Text?

## MimeMediaRecord

This is missing from the Intel version, I think it's needed.

## Smart Posters

Have you considered records for Smart Poster? Are there plans to insulate
the API user from the nested NDEF message inside the Smart Poster? e.g.
smartPoster.getTitle("en"); smartPoster.getTitle("fr"); smartPoster.getURI()

## Other record types

The concrete objects are nice when they exist. Will the API handle other
types as well? This could include "standard" types like Android Application
Record (AAR) or types that users create.

========================
NfcTag
========================

I'd like to see more meta information in the tag.  I think all this needs
to be optional since platforms like BlackBerry 10 and Windows Phone 8 don't
return any non-NDEF info.

NfcTag
    UniqueID byte[]
    getId() return as id hex String
    TagType { NFC_FORUM_TYPE_1, NFC_FORUM_TYPE_2, NFC_FORUM_TYPE_3,
NFC_FORUM_TYPE_4, Mifare Classic }
    TagTech {"OTHERS", "NFCA", "NFCB", "NFCF", "NFCV", "ISODEP", "NDEF"};
    Capacity number of bytes
    Free Space number of bytes
    Locked (or Writable)  boolean
    Lockable boolean

===============
FailureCallback
===============

I'd suggest renaming FailCallBack to FailureCallback and rename fail to
failure, since it reads better.

FailureCallback should include an (optional) String argument with the error
message or perhaps an object.

    function failure(errorMessage);

===============
addListener
===============

in spec
   void addListener(NfcEventCallBack listener, SuccessCallBack success,
FailCallBack fail);

suggested change
    void addListener(NfcEventCallback listener, FailureCallback failure);

Similar to the Webinos API, my PhoneGap API has 3 arguments when adding
listeners.

After using listener code for a while, I don't think the SuccessCallback is
useful.  It never really gets used.  The FailureCallback is called when
something goes wrong.  The listener is called when a tag is scanned.

As for events vs callbacks.  I think this could be more of an
implementation detail that can be mostly hidden from the called. Currently
I fire a JavaScript events when a tag is scanned.  This works fine for
Android and Blackberry  For Windows 8 using the callback would be more
convenient. I'm considering switching all platforms to using the callback
instead of firing a Javascript event.

=============================
multiple listeners and order
=============================

How will the different listeners work?  For example if a tag is scanned and
a user has added listener and a uri listener.

Currently, Android calls the most specific listener that matches the tag.
 Blackberry 7 calls ALL the listeners that match the tag.  It might be good
to define the how this should work.

=============================
sharing tags and peer to peer
=============================
I'm seeing differences on how sharing tags works across platforms. e.g.
Android shares until stop is called. Blackberry 10 shares until the tag is
read. Windows 8 wants a client to be in range before the tag is shared.

I need to implement more peer to peer code, ideally between PhoneGap and
Arduino. I'm going to try out some of the ideas from the current specs to
see what works.




On Tue, Mar 5, 2013 at 5:04 AM, Yriarte, Luc <luc.yriarte@intel.com> wrote:

> Hi all,
>
> It really was a pleasure to meet you guys last week at MWC, I hope you had
> a nice trip back. Working towards a common NFC draft, I'd like to setup a
> list of items that every side wants, so that they would be included in the
> spec. Feel free to add stuff as appropriate. For reference, the existing
> APIs are here:
> http://w3c.github.com/nfc/proposals/intel/nfc.html
> http://w3c.github.com/nfc/proposals/webinos/nfc.html
>
>
> What I'd like to take from the Tizen API:
> - A NDEFMessage interface that's an array of NDEFRecords, and the
> inheritance hierarchy of NDEFRecord types
> - Separate NFCTag and NFCPeer interfaces, each having their own methods
> for reading / writing or sending / receiving NDEF Messages. That allows
> registering a listener for NDEF messages on a peer device, that could send
> a bulk of messages, but just invoking a "read" method on a tag. Also, all
> the pairing / handover stuff is done at the NFCPeer interface level. BTW
> last week's slides, including the updated spec with BT handover, are
> accessible there:
> https://github.com/01org/cloud-neard/wiki
>
>
> What I'd like to take from the Webinos API:
> - It's event-based. Right now the Tizen-based API uses only callbacks, and
> that would not work well with the Webinos / node.js framework. If I
> understood correctly what Hans explained the node.js implementation uses
> HTML5 server-sent events. The Javascript code runs on the device, raise a
> very light http server, and the UI code in the web browser registers for
> server events. Please correct me if I'm wrong.
> Anyway I believe it would make sense to align with the EventTarget /
> EventHandler model of the Sysapps group proposals like Telephony, Messaging
> and so on
> http://www.w3.org/2012/sysapps/
>
>
> As far as I'm concerned that's what I consider is important to get right,
> I have no strong opinion on what to do with MIME / binary data, lower level
> comms (LLCP), read only tags... please add your opinions and what you feel
> strongly about.
>
> Cheers,
>
> Luc
>
> Luc YRIARTE - OTC Software Engineer
> INTEL Corp. Montpellier, France
>
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>