On Wednesday 04 February 2009 00:00:44 Martin Preuss wrote: > As I see it the situation is this: There are applications which mandatory use > the SCard interface provided by libpcsclite. There are other > applications/libraries that can optionally use the SCard interface (as is the > case with OpenSC). And there are applications which can't use pcsc (in fact, > there are applications which are prevented from working while pcscd is > active), but which can use a wrapper (e.g. CTAPI applications like Moneyplex > and most application in the medical field in DE).
True. This is why I suggest separating the reader framework from the application API. The reader framework I outlined will enable PC/SC, CT or any other API to use the framework at the same time. > So the question is: Wouldn't it be best to concentrate on improving the pcsc > daemon instead of maintaining multiple other frameworks? Maintaining multiple frameworks is not an option. pcscd needs revolution in order to support what I require and also what you wrote bellow. > 2) it would be nice to have non-blocking access, especially when working with > a GUI. I know that this could be implemented in the application by using > threads, but it would be much nicer to have this in the API. Yes, I had this need too... One of my goals of the new framework is to provide none blocking access. Remember that PC/SC API will use the new framework, but it won't block you from using the framework API directly. > [...] > > As Andreas said, OpenSC is in decline, and pcsc-lite project maintain > > only single CCID driver. Joining forces is the only way we can give > > this another chance. Every way we can make the implementation simpler > > and cleaner will help free future resources to deal with improving the > > offering. > [...] > > I believe Andreas was talking about OpenCT as being in decline, not OpenSC. No... OpenSC and OpenCT. > [...] > > 6. The configuration of hardware resides in pcscd, while correct practices > > imply placing this repository within the hotplug service. > [...] > > What exactly do you mean by "configuration of hardware"? Shouldn't this be > done by the driver? For example the USB vendor:device ids... pcscd has its own repository (via driver) While these days you expect it to provide configuration to hald or udev. Thanks, Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
