Parse environnement vars and files to load nfc devices options

[GoogleCodeExporter]

It would be nice to have some default options for nfc examples to select the 
reader:

nfc-list --driver=pn532_uart --device=/dev/ttyUSB1 --speed=11500

or:

nfc-list --device="pn532_uart:/dev/ttyUSB1:11500"

Original issue reported on code.google.com by emanuele.bertoldi on 14 Jun 2010 at 2:17

[GoogleCodeExporter]

That's a great idea... but the windows support of command line parsing is 
boring : each type we try to do something more nicer/cleaner, windows support 
is broken... And we terribly lack of windows contributions.

Original comment by romu...@libnfc.org on 20 Jul 2010 at 1:54

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've implemented a first prototype (r455) which works in nfc-list example:

nfc-list --device PN532_UART:/dev/ttyUSB0:115200

Original comment by emanuele.bertoldi on 22 Jul 2010 at 1:44

[GoogleCodeExporter]

So Zuck, do you consider this issue closed ?

Original comment by romu...@libnfc.org on 31 Aug 2010 at 1:35

[GoogleCodeExporter]

In my opinion, all libnfc examples should have this feature implemented.

Original comment by emanuele.bertoldi on 31 Aug 2010 at 2:38

[GoogleCodeExporter]

Ok, so I leave this issue opened for now

Original comment by romu...@libnfc.org on 31 Aug 2010 at 2:41

[GoogleCodeExporter]

Why not using sth more global, parsed directly by libnfc rather than by
each application?
E.g. an environment variable or a preference file if there is more than a few 
global options.

export LIBNFC_DEVICE="PN532_UART:/dev/ttyUSB0:115200"
export LIBNFC_DEVICE="PN532_UART:/dev/ttyUSB0:115200;PN533_USB"
etc

Usually you've default options hardcoded in a prog, superseded by options you 
set in a global preferences file, superseded by options you set in a personal 
preferences file, superseded by options you set in environment variables, 
superseded by options you give on the command line.
We don't need to have everything but it's just to get the picture.

Original comment by yob...@gmail.com on 27 Sep 2010 at 9:17

[GoogleCodeExporter]

IMHO, using a preference file for a library is not efficient: if you want to 
use one device with an application and one another file for another application 
is a little bit messy.

BTW, environment variable is a great idea from my point of view.

Original comment by romu...@libnfc.org on 28 Sep 2010 at 8:35

[GoogleCodeExporter]

Hum, AFAIAC, I think that environment variable should be used only for a 
particular run (e.g. env FOO=bar ./prog)  or if these is no point for a 
configuration file (e.g. $PATH, $HOME) ...

Since these preferences are not likely to change for the end-user, it make 
sense to have a configuration file, and optionally a way to override it through 
environment variables.  The config file could be system-wide 
(/etc/libnfc.conf), user-dependant (~/.libnfc.conf) or application-dependant 
(~/.application.conf).

For a more detailed explanation of the benefits, see how malloc(3) can be 
tweaked on FreeBSD (seems to be less customizable with a GNU libc):
http://www.freebsd.org/cgi/man.cgi?query=malloc

Another cool stuff with configuration file is the possibility to easily assign 
a firendly name to an initiator (nfc_connect_by_name ("snapper"); ), and the 
possibility to change the device an application use without compiling the 
program again nor having to update some obscure environment variable: I guess 
editing a configuration file is more logicial.

Original comment by romain.t...@gmail.com on 28 Sep 2010 at 11:49

[GoogleCodeExporter]

From my point of view, parsing multiple files (system-wide, user-dependant and 
application-dependant) on each load of the library is not efficient. Don't you 
think so ?

Original comment by romu...@libnfc.org on 28 Sep 2010 at 1:05

[GoogleCodeExporter]

Well, my opinion is that there is so much things done by the system under the 
hood when a program is launched that reading a configuration files will have no 
inpact on performances (editing links of dynamic binaries is far more complex I 
guess, and even the liker reads configuration files! /etc/libmap.conf 
/var/run/ld-elf.so.hints not to name them).

Of course, if we consider we might not have a filesystem on an embeded device, 
the problem is different. But in such a case, I guess the best is to have the 
information required to use a given NFC device hard-coded in the firmware and 
require a firmware update to switch device.

As a result, I think all these solutions makes sense depending of the context.  
Maybe we can provide them all and allow the developper to either:
  1. directly fill-in a nfc_device_desc_t struct;
  2. load a set of nfc_device_desc_t struct from a configuration file and select a device by name;
  3. ask plugins to probe for devices and return a set of nfc_device_desc_t.

Currently:
  - Points 1 and 3 are already implemented.
  - We are conscious that 3 is buggy (in particular for UART devices).

A tool nfc-scan which generate a configuration file would have my favour, but 
has the drwback of not being straightforward for a desktop use.  DBus might 
help integration with the desktop but it's a PITA...  Well, I don't have a 
solution, but maybe these elements will help you to find one!

Original comment by romain.t...@gmail.com on 28 Sep 2010 at 4:34

[GoogleCodeExporter]

BTW first proto of r455 works only for serial devices, and is broken for USB 
devices.
See e.g. code of nfc-list how to select a USB device.

Original comment by yob...@gmail.com on 5 Oct 2010 at 1:38

[GoogleCodeExporter]

Original comment by romu...@libnfc.org on 30 Dec 2010 at 10:59

• Changed title: Parse environnement vars and files to load nfc devices options
• Changed state: Accepted
• Added labels: Priority-Medium, OpSys-All, Milestone-1.6.x, Usability
• Removed labels: Priority-Low

[GoogleCodeExporter]

I replaced nfc_device_desc_t with a connection string in libnfc-1.5-new-api 
branch (r1170).
IMHO, this issue could now be considered as fixed, since argument parsing is 
easy to do at user-application level and we now provide a default device if 
LIBNFC_DEFAULT_DEVICE environment variable is set.
If someone think there is some miss here, feel free to re-open it!

Original comment by romu...@libnfc.org on 17 Oct 2011 at 1:22

• Changed state: Fixed