On 17 Jan 2010, at 10:15, Ludovic Rousseau wrote: > 2009/10/8 Ludovic Rousseau <[email protected]>: > > Jean-Luc Giraud worked on a test suite to check the behavior of PC/SC > function regarding blocking. The program is available at [1]. > .... > > The Windows functions are blocking (except for SCardGetAttrib). But > most of the pcsc-lite functions will return SCARD_E_SHARING_VIOLATION > instead. > ... > Do you think it is a good change to make pcsc-lite calls block instead > of returning SCARD_E_SHARING_VIOLATION? I don't think Windows provides > a timeout or something similar so the call may be blocked for a long > time.
It seems that there has not been much interest in this topic to say the least. I would consider this as good news: not many people have been "burnt" by the difference. I see 2 potential reasons: 1- The smart card software that they developed was not required to be cross-platform (it was either a green field project or an adaptation of a Windows source that was not required to be cross-platform). 2- They have not have had to ever deal with this difference in behaviour because their software does not use transactions (SCardBegin/EndTransaction) and they have been able to write cross-platform drivers without problems. I would not be surprised if 2- was the main cause: most smart card host software assumes that it has exclusive access to the card (because it is the only known driver for that type of card). So developers never bother to use transactions and so far it has never caused an issue ( because "which other piece of software could be interested in talking to _our_ card????"). This status-quo could be challenged in the future: A- Multi-applicative cards that really contain multiple applications could appear on the market one day (I am not holding my breath on this one). Then the e-purse driver may want to access the card while a PKCS#11 library is generating a signature. B- Remote access technologies (e.g. X WIndow or Windows Terminal Services) may want allow the remote machine to access the local card at the PC/SC level. This will lead to contention issue if/when the local and remote drivers try to access the card at the same time. So in preparation for these eventualities and to facilitate the production of cross-platform code, I'd like to improve the compatibility between pcsclite and Windows' PC/SC while we can. So please give us some feedback on whether you think this is a good or a bad idea. Cheers, JL.
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
