I want to get a "reliable" connection to the smart card. Right now there is an option to specify either shared or exclusive access to a reader during connect(). Exclusive access is the best option, but it is not always possible in real life situations - some other system app keeps a an idle connection to the reader open, for example. For such situations SCard(Begin|End)Transaction could be used, together with a shared connection.
expose SCard*Transaction calls on JS API level. This leaves the burden of transaction management to the app developer
hide the complexity from app developer and add an option to connect() that would indicate "shared mode transactions", which would call SCardBeginTransaction on non-windows platforms, together with SCardConnect. And give a synthesized SCARD_E_SHARING_VIOLATION error if this fails for some reason.
From flexibility POV, the first option would be best, from ease of use and 'DWIM' interface POV, I would probably wrap the exposed transaction mechanism behind a connect() wrapper before use, anyway.
I want to get a "reliable" connection to the smart card. Right now there is an option to specify either shared or exclusive access to a reader during connect(). Exclusive access is the best option, but it is not always possible in real life situations - some other system app keeps a an idle connection to the reader open, for example. For such situations
SCard(Begin|End)Transactioncould be used, together with a shared connection.This is sometimes worse than a plain shared connection, as Windows 8+ have a "5 second rule" for transactions (see Remarks in MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379469(v=vs.85).aspx)
There are at least two paths to a solution:
SCard*Transactioncalls on JS API level. This leaves the burden of transaction management to the app developerconnect()that would indicate "shared mode transactions", which would call SCardBeginTransaction on non-windows platforms, together withSCardConnect. And give a synthesized SCARD_E_SHARING_VIOLATION error if this fails for some reason.From flexibility POV, the first option would be best, from ease of use and 'DWIM' interface POV, I would probably wrap the exposed transaction mechanism behind a connect() wrapper before use, anyway.