RE: Towards a common NFC draft...

Hi Don,

First, let me say we appreciate the feedback :) and also, it's nice to have someone working on phonegap posting here. I have inlined some answers to your comments, but just to get the main idea: we started with a stripped down version of the Tizen API, with just Tag reading / writing, and Peer send / receive message. So yes, many things are missing, the goal - I hope - is to add them back, from the ground up. Also, I'm no NFC expert here - I'm more drafting the API. I'll let Samuel or others correct me if I'm wrong, and complete my answers...
 

> 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?

Encoding is an attribute of the Text record, I'd say we'd use UTF-8 by default rather than ASCII

> 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) }

I have no strong opinion on this. On the one hand, the API design cookbook recommends strings http://www.w3.org/TR/api-design/#numerical-constants but on the other hand, TNF is already specified as a number by the NFC spec...

> How is the Intel spec handling binary payloads? 

I think it would be nice to handle MIME data using the Media Capture API http://www.w3.org/TR/html-media-capture/ without having to get dirty with byte arrays in Javascript... but that probably won't solve all the use cases, so it's likely we'll still need a byte array in the end


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

Indeed. Just looking for some smart way to handle this without having to manipulate media content as a byte array.

> FailureCallback should include an (optional) String argument with the error message or perhaps an object.
>
>    function failure(errorMessage);

We're trying to move from success / error callbacks to EventTarget objects / promises.
http://www.w3.org/TR/api-design/#dfn-returning-an-eventtarget-object
http://sysapps.github.com/sysapps/proposals/Telephony/Telephony.html


> 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.

The success callback for adding a listener doesn't make much sense, I agree. Here, using the EventTarget object and only setting a 'onerror' EventHandler would work.

>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.

The nice thing with EventTarget objects, as I understand, is that they work both ways. One can call a EventHandler as a callback, with an event as parameter, or just fire the event.

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

We were more thinking of having one Tag / Peer generic listeners, instead of content-specific listeners. The app would choose what to do in the listener, according to the content type.

... Sorry for passing on the NDEF content / record type inferring from TNF questions. I'll let Samuel or others chime in :)

Cheers,

Luc



---------------------------------------------------------------------
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.

Received on Wednesday, 6 March 2013 18:30:11 UTC