991223 - Refactor existing NFC WebIDL (MozNFCTag) to support new technogies such as ISODEP , etc.

Status: RESOLVED INVALID

(Firefox OS Graveyard :: NFC, defect)

Description

[psiddh]

Based on the comments @ https://bugzilla.mozilla.org/show_bug.cgi?id=916428 ,
should we rename MozNFCTag to MozNDEFTag and have it derived from a base class that contains basic functions?

Comment 1

[Junichi Hashimoto]

I agree with you. 'timeout' field should be contained in the base class to give time restriction for any operations.

Comment 2

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Siddartha P from comment #0)
> Based on the comments @ https://bugzilla.mozilla.org/show_bug.cgi?id=916428 ,
> should we rename MozNFCTag to MozNDEFTag and have it derived from a base
> class that contains basic functions?

Do you have any update on this?
What's the reason to rename it?
Doesn't current MozNFCTag already contain 'basic functions'?

Comment 3

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Junichi Hashimoto from comment #1)
> I agree with you. 'timeout' field should be contained in the base class to
> give time restriction for any operations.

Hi Junichi-san
Sorry but I think 'timeout' value is not related to this bug.
Feel free to file another bug to provide your reason and discuss this.

Comment 4

[psiddh]

>Do you have any update on this?
>What's the reason to rename it?
>Doesn't current MozNFCTag already contain 'basic functions'?

Hi Yoshi,

In order to support different technologies such as IsoDep, MiFareUL , NFCA , NFCB etc., we may have to re-factor our existing webIDLs.
Our current MozNFCTag() is too NDEF specific. This is OK as long as we only support NDEF technology. With KDDI near future plans to add 'IsoDEP' support, and in general for seamless integration of other new technology implementation, it is a good idea to consider to re-factor our existing IDLs.

Every technology (including NDEF, i,e; our current MozNFCTag() implementation) should support basic functions such as connect(...) , close(...). Also perhaps the basic functions list increases (if we are supporting multiple/different technologies) : 'reconnect(...) , isConnected(...)' etc.

Instead of having basic functions repeated in all specific technology interfaces, we may have to re-factor it to a standard Base Class <--> Derived Class pardigm. This also enables us to nicely integrate newer technologies in future.

Base Class in this case can be MozNFCTag() which contains connect(..), close(..), 'reconnect(...)', 'maybe even transceive(..) and timeout attributes' while derived classes of MozNFCTag say, MozNdef may add its specific interfaces such as readNDEF(..), getDetailsNDEF(..) etc..  and say MozMifareUL has to support at-least additional two new interfaces readPages(..) , writePages(...). 

Also I have prototyped this re-factoring (note that this is not complete yet) for your reference.
https://bug916428.bugzilla.mozilla.org/attachment.cgi?id=8396611

Some noteworthy changes are:-
getNFCTag(sessionToken) to getNFCTag(sessionToken, enumTechType)  and have a case statement to initialize different technology classes based on arg 'enumTechType'.

Gaia app developers can then do

var ndef = mozNfc.getNFCTag('1234', 'NDEF'); 
ndef.writeNdef(..)

    or

var isodep = mozNfc.getNFCTag('1234', 'iso_dep');

KDDI team has uploaded a nice class diagram depicting the same.
https://bug916428.bugzilla.mozilla.org/attachment.cgi?id=8396870

Thanks

Comment 5

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Siddartha P from comment #4)
> Hi Yoshi,
> 
> In order to support different technologies such as IsoDep, MiFareUL , NFCA ,
> NFCB etc., we may have to re-factor our existing webIDLs.
> Our current MozNFCTag() is too NDEF specific. This is OK as long as we only
> support NDEF technology. With KDDI near future plans to add 'IsoDEP'
> support, and in general for seamless integration of other new technology
> implementation, it is a good idea to consider to re-factor our existing IDLs.
> 

Thanks for explaning, Sid.

However in your cases, IsoDep/NfcA/NfcB are of Type 4 tag, MifareUL is of Type 2, NfcF (Felica) is of Type 3, all they should support NDEF by NFC-Forum.

It seems to me we don't have to do this for now, unless we want to support non-NFC-Forum tags.

Comment 6

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

If no furthur comments please close this as Invalid.

Comment 7

[psiddh]

Yoshi,
What would be the plan to support IsoDep feature and say , transceive(..) API ? Since this bug was a follow-up bug to https://bugzilla.mozilla.org/show_bug.cgi?id=916428. Based on the patch uploaded in bug#916428, 'transceive' will exist in MozNFCTag() interface. 
Requesting KDDI team to share their insights too.

Comment 8

[psiddh]

Yoshi,
What would be the plan to support IsoDep feature and say , transceive(..) API ? Since this bug was a follow-up bug to https://bugzilla.mozilla.org/show_bug.cgi?id=916428. Based on the patch uploaded in bug#916428, 'transceive' will exist in MozNFCTag() interface. 
Requesting KDDI team to share their insights too.

Comment 9

[Junichi Hashimoto]

As you know, NCF has 3 main features: Reader/Writer, Card Emulation and P2P.

NDEF supports only static data Read/Write with tags. But existing IC cards have more dynamic functions such as challenge-response authentication.
Without transceive() API, FxOS and apps cannot access such functions.

Comment 10

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Siddartha P from comment #8)
> Yoshi,
> What would be the plan to support IsoDep feature and say , transceive(..)
> API ? Since this bug was a follow-up bug to
> https://bugzilla.mozilla.org/show_bug.cgi?id=916428. Based on the patch
> uploaded in bug#916428, 'transceive' will exist in MozNFCTag() interface. 
> Requesting KDDI team to share their insights too.

'transceive' is implemeneted in another bug, and I don't think it's related to this bug (seperator NDEF functionas from MozNFCTag).
Given there's no reason to do this, close this as INVALID.