Hello, As I said in [1] I will modify SCardControl() to use the same API as the one under Windows PC/SC. This will break the API so we will have side effects on existing applications.
I plan to: - increase the library number so that libpcsclite0 and libpcsclite1 can coexist on the same system - add a protocol version dialog between the libpcsclite1 and pcscd so that they can both know the API version of the other side - when called from libpcsclite0 the new pcscd will provide the old SCardControl() API used by driver implementing IFD Handler v1 and v2 - when called from libpcsclite1 the new pcscd will provide the new SCardControl() API used by driver implementing IFD Handler v3 - SCardControl() used from libpcsclite1 with a v1 or v2 IFD Handler will work but the tag (new argument) will be ignored. What will not work? - libpcsclite1 with an old pcscd - SCardControl() used from libpcsclite0 with a v3 IFD Handler (my CCID driver for example) With this we will have: - existing applications will continue to work even when pcscd is updated and libpcsclite1 is installed - easy upgrade for existing applications - if your application does not use SCardControl() you will just need to recompile and link with libpcsclite1 instead of libpcsclite0 - if your application uses SCardControl() just add a dummy argument (set it to 0 to be safe) to recompile with libpcsclite1 Note that the ifd handler v3 will be introduced with the new pcsc-lite. So we can impose the new SCardControl API on it. I think this transition plan in smooth enough. If you see protential problems, please, tell me. And last but not least: I hope I will be able to implement what I propose above :-) Bye, [1] http://archives.neohapsis.com/archives/dev/muscle/2004-q1/0395.html -- Dr. Ludovic Rousseau [EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
