Am Montag 02 Februar 2009 19:27:42 schrieb Douglas E. Engert: > > The way to do this is to have a single service which provides a > > rendesvous point for clients and readers, keeps track of what readers > > exist and of their state, informs clients of changes they are interested > > in, and mediates when more than one client wishes to access the same > > reader. > > That sounds a lot like pcscd! > > Noting that MacOS and Windows use the pc/sc model, it is not clear why > OpenSC want to move away from it.
count me in on that question. I understand that alon likes the openct design (no threads, only one process per reader etc.), but that design has a lot of limitations. also openct has a lot less to offer than pcsc-lite plus ccid, for example no working pinpad support. I believe if all things pcsc-lite plus ccid can do would be added to a design similar to openct, the end result would not be much different. sure, pcsc-lite is complex, and when I had too much trouble with it in 2003 I choose to implement "usbtoken" which integrated my etoken driver directly with opensc in 400 lines of code - so it was much easier than trying to figure out the pcsc-lite internals. but then the goals where low (get a few simple keys to work with opensc), and the pcsc-lite maintainer didn't at that time didn't answer my emails. but today pcsc-lite is active maintained by ludovic, has a huge amount of features, and works well. I wonder why anyone would want to spend a huge amount of time to get similar features ported to / written for openct or some new design. but this is open source, we don't stop anyone from writing new code, competition is good. so if alon wants to explore new ideas, let him, why not? but I didn't read anything that ludovic is interested in implementing these ideas alon has. I wouldn't mind if ludovic is not, after all pcscd works well, ccid works well, why change anything? and aren't there more interesting things to do than write a pcsc+openct successor? but well, everyone free to spend the time he has however he wants. make sure what you do is fun to you! so alon, if you want to hack on pcsc-lite, why not fork it,change it, and present your changes later as patches? that is much easier than discussing unimplemented designs of proof-of-concent code far from real-world-usability. the linux kernels has a huge emphasis on "show us the code" and it seems to work well for them. but all I do is idle talk - I didn't contribute much code to opensc and friends, and all the idea of what could be done and how to do it got not implemented in 95% of the cases. sure, I wrote documentation and tested and created releases. but without a real core developer opensc will go nowhere, and the same can be said about openct and friends. these projects are not rising stars, they are projects in decline and have been for years - even though new code (e.g. new drivers) were added here and there. all we can do is manage the decline (e.g. small fixes, apply patches etc), unless someone with lots of time to invest shows up. back to the mails exchanged here: alon, you can't ask ludovic to "migrate the PC/SC API into the new framework." that is unreasonable, the current code works well, and I haven't seen new code. all you can do is write new code, publish it, get feedback, and see if people like the new code or not. but - reality check - one feature of the new code would be thread-less, right? I'm not sure you can implement multi-slot readers without threads (or if you can: wouldn't that have about the same complexity)? also as far as I know you can't use usb on mac os X without threads. pcsc-lite is *the* smart card middleware on non-windows, asking any change that might reduce the number of supported plattforms is not likely to find many fans. so you would need to show that the new design you plan works on mac os X too (and is as stable and then still has benefits over the old design). also I believe pcsc-lite works on many old and exotic systems. for example "hotplug service" is something we have on linux. but older unixes, bsd systems, embedded systems? I'm not too sure here. in fact I used to be happy about the linux hotlug stuff starting in 2003, and all these years it was a pain for me to get openct to work on non-linux. maybe the situation has improved a lot meanwhile, I don't know. finally I don't think that moving away from pcsc standard interface is good. openct has its own interface, and never found more than one user. why would a new interface be adopted by more people? one the other hand I understand ludovics original posting: day to day we see many people having installed both openct and ccid and pcsc- lite and discussing their setups to find the problem is tiresome. so changing the default setup to cause fewer support requests is maybe a good idea. only I would prefer, if we could somehow migrate other drivers to pcsc-lite as well, and not only look at ccid. and do the whole thing without maintaining lots of duplicate code. I don't mean any disrespect for the ccid driver in openct, and I'm very sorry Chaskiel if anything I wrote hurt you, I didn't mean to. I only see that ludovics ccid has more feature and he spends much time on supporting it and keeping it and pcsc-lite alive, while there is nearly noone working on openct (except for alon and the recent changes he introduced there was a long periode of silence before that). so judgeing from this situation only I think users are better off with libccid and pcsc-lite (and it creates less support work for us, too). so, sorry for the long mail and many bcc's and thanks for the attention. I don't mean to insult anyone, only to mediate and show some different point of views on the situation. please forgive me if I made mistakes and hurt or insulted anyone this way. Thanks and regards, Andreas _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
