Hi list, just a few thoughts from an outsider to OpenSC:
On Dienstag, 3. Februar 2009, Alon Bar-Lev wrote: [...] > I think a lot has changed since year 2000. Design practices were changed > from blocking, threaded, single process model to none blocking, single > threaded model. The number of popular operating system reduces... We have [...] Those really are interesting points. I remember a short discussion about converging the multiple reader access frameworks last year or so. [...] > I truly believe that a good reader framework will have great advantages. > For example, convincing the projects that access the device directly to > use a simple API, while providing other standard APIs (PC/SC, CT), > the other technical stuff is also important (hotplug, driver simplicity > etc). [...] 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). Also, PC/SC is a well established industry standard, and besides Open Source drivers there are proprietary drivers for PC/SC. Libpcsclite is also portable and in use on several systems. Also, the code looks very efficient. So the question is: Wouldn't it be best to concentrate on improving the pcsc daemon instead of maintaining multiple other frameworks? As an author of "one of the other frameworks" I decided some time ago to switch to PC/SC as the ressource manager. However, there are some issues with pcscd which prevent me from dropping my own ressource management completely: 1) with pcscd all readers are always *on*. As soon as a reader is connected it is started and polled for card insertion and removal even when there is no client. I would very much like the pcscd to only power up a reader if there is at least one client. This also serves as a nice visual control (on my system I have reason to be suspicious if a reader suddenly starts up unless I actually started a client myself). 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. 3) I like the idea of having a driver running inside its own process (as Alon proposes) as opposed to using threads. That way a problem of a driver doesn't affect the daemon. This is especially important to me when proprietary drivers are used: I feel much safer if such a driver doesn't have control over the whole daemon process. While the second point will probably never be implemented unless it becomes part of the PC/SC specs (which I doubt) I believe the first point should be considered, especially when it comes to laptops. Given the fact that pcscd works quite well under most circumstances and is also well established it might be better to work on improving this already working framework instead of starting the long time task of creating a new one. [...] > 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. [...] > 3. pcscd runs as root, while not require it. [...] That should be easy enough to change. [...] > 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? [...] Just my 2cents, feel free to ignore ;-) Regards Martin -- "Things are only impossible until they're not" Martin Preuss - http://www2.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
