On 03.05.2007, at 0:38, Martin Preuss wrote: > I don't like this situation any more than you do, but that's how it > is right > now. In this situation I don't find it helpfull if any interface > exclusively > grabs all readers, thereby blocking any other interface. > > I know that at least the PC/SC developers want to keep it that way, > but I > still feel entitled to my own (in this case: different) opinion on > that. > That's why I changed Libchipcard's behaviour from the same excluding > behaviour to a less aggressive one.
... > In general I don't have problems with having a variety of APIs > (although one > single API would greatly simplify the application programmers work) > as long > as none of them tries to bind the readers exclusively. Please describe the situation and motivation behind this. Why does it matter if pcscd grabs the readers ? Because existing CTAPI drivers (needed for secure communication with the reader) are then blocked out ? Why not bomb reader companies to deal with the driver (and thus API) problem ? What should be done differently (except for the design decision 'grab or not to grab') so that there could be only one reader access layer/api/library on Linux that would focus on 'card communication via whatever channel' ? Libchipcard works on Windows (partially). This means it SHOULD work on linux/mac via pcsclite as well (given my assumption that most ctapi drivers are implemented on top of pcsc is correct). m. -- Martin Paljak _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
