On Wednesday 02 May 2007 23:52, Martin Paljak wrote: > On 03.05.2007, at 0:38, Martin Preuss wrote: [...] > > 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 ? [...] I don't think that reader manufacturers care that much about Linux (some do, but the majority doesn't). Meanwhile we have to deal with the situation as it is.
[...] > 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' ? [...] On the lowest layer I need at least: - support for different driver types (especially IFD and CTAPI, since there still are drivers for both interfaces) - commands: - look for a card, wait for insertion if necessary - lock/unlock a card - send commands - release card - information: Manufacturer of the reader, driver/firmware version if possible etc. This is needed for abstraction of differences in APDU's on different readers. - access to both processor *and* memory cards In addition I'd like to have (and therefore implemented it in Libchipcard): - secure access to readers at remote hosts (not as remote as via internet but within an intranet) - the master-slave model described in the document Micha linked to in his mail), this is needed for thin-client support provided for Gnumed [...] > 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). [...] It *does* work over PC/SC, but that interface doesn't let me use CTAPI drivers so it excludes those readers for which there only are CTAPI drivers (which could of course be circumvented by adding an IFD-CTAPI wrapper). Also, currently there is no standard way how to use memory cards on every PC/SC implementation: pcsclite allows me to connect such cards by specifying the protocol "raw" but that doesn't work on Windows and it also doesn't work with some proprietary (binary-only) readers. And last, but certainly not least, is the issue with the definitions of DWORD etc which prevents mixing of 32- and 64 bit clients with one pcscd (or have this meanwhile been solved? And what about the byteorder stuff? Is that solved?) Regards Martin -- "Things are only impossible until they're not" AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
