dotnfc / libnfc

Automatically exported from code.google.com/p/libnfc
GNU Lesser General Public License v3.0
1 stars 0 forks source link

nfc_emulate_target() with timeout #216

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Currently nfc_emulate_target() implementation uses 
nfc_target_init()/nfc_target_send_bytes()/nfc_target_receive_bytes()
with timeout value 0. This blocks the emulation indefinitely until error is 
raised or function is completed.

There could be a method to use the same functionality with timeout.

Original issue reported on code.google.com by raidolinja on 19 Dec 2012 at 12:45

GoogleCodeExporter commented 9 years ago
Improvement in change:
https://code.google.com/r/raidolinja-nfcemulatetargettimeout/source/detail?r=f66
28c7f10db09c8da76e73133d3788c0b206785

Original comment by raidolinja on 19 Dec 2012 at 1:20

GoogleCodeExporter commented 9 years ago
I purpose a solution that seems better to me:

Instead of an hardcoded "0" value (infinite timeout) in these functions, we can 
set "-1" (use default value), this way it let the user know which timeout to 
apply to these functions.

Concretely, instead of:

nfc_emulate_target_timeout(pnd, emulator, user_timeout);

we can do this (without API break or additionnal functions):

nfc_device_set_property_int(pnd, NP_TIMEOUT_COMMAND, user_timeout);
nfc_emulate_target(pnd, emulator);

What do you thin about this ?

Original comment by romu...@libnfc.org on 28 Jan 2013 at 7:06

GoogleCodeExporter commented 9 years ago
Mm this changes the overall default timeout value and might have side effects 
later.
One way would be to get & save the default value before & restoring it after 
but this becomes cumbersome and if someone doesn't know he needs to do that 
he'll run into problems.
E.g. if he doesn't set the timeout, default timeout will be way too short and 
if he does set it=0 (infinite), he may run into problems with next commands if 
default becomes infinite.

We hate API changes but, well, it makes sense here IMHO.

Original comment by yob...@gmail.com on 29 Jan 2013 at 12:08

GoogleCodeExporter commented 9 years ago
There is no point to keep a function with infinite hardcoded timeout.

Original comment by romu...@libnfc.org on 29 Jan 2013 at 11:11

GoogleCodeExporter commented 9 years ago
This issue was closed by revision cd2b03a08a4f.

Thanks!

Original comment by romu...@libnfc.org on 29 Jan 2013 at 11:14