On Monday 02 February 2009 21:58:17 Andreas Jellinghaus wrote: > of limitations. also openct has a lot less to offer than pcsc-lite plus ccid, > for example no working pinpad support.
This is driver issue not framework issue. > 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. Yes it will I tried to demonstrate it in my earlier post. > 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? One of my main goals was to work *WITH* Ludovic in order to separate the PC/SC API from the reader infrastructure, allowing much more simpler implementation of the reader part. I always wrote that I won't create another competing project, if Ludovic don't see any advantage I drop the idea. But as a user I don't have a solution for mdev/udev only environment, pcscd waste my battery. And as a developer is too complex for me to contribute. So as long as we have openct I prefer to use it. > 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. I already sent in the mailing list the interface I thought suitable for this design. You can review it... pcscd cannot be migrated without revolution. > 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. As I said before, PC/SC API is simple enough to be client only API. Current PC/SC design extends the PC/SC API to the driver, which is unrelated. This model does not allow none PC/SC application to work with the same drivers. And I believe this waste a lot of resources in the community. > 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)? No. You have a file descriptor of usb and poll it. You can also handle several readers... You have two file descriptors and poll them... Nothing fancy. Simple and working. It is like you suggest that implementing a web server requires threads... While having more threads than the number of CPUs actually wastes resources. > also as far as I know you can't use usb on mac os X without threads. So on this platform you have helper thread that wakes up the main... But on decent platforms you are not forced to use complex solution. > 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). PC/SC API is the interface. I thought that combining resources may introduce the same API in more simple reader architecture. > 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. This is also not a problem, as I suggested long ago to Ludovic regarding pcscd in initramfs environment, it is easy to implement libusb enabled daemon that polls for new devices and forks the reader daemon. > 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? Again... were did you got that impression?!?!?!?! I *NEVER* wrote PC/SC API will not be available! Just that instead the reader drivers support PC/SC directly you separate between application API and reader API, in a way that the reader API is clean and may support any interface required. > 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. I think the only mistake is technical. The offering providing to users is not satisfactory in both projects. What I want is for us to work together and look for a better way to invest the resources we have. We can take openct as a baseline, add event support to the API and implement PC/SC using OpenCT API as a separate library. Then convert the IFD CCID driver and merge it into openct (removing libusb usage, threads, polling etc...) We can take pcsc-lite as a baseline, but it is too complex to separate the PC/SC API without rewrite the whole daemon. Then it would be hard to make it support process per reader. And we can design a new reader library which may be used by PC/SC library, supporting IFD interface at start, then migrate drivers to more efficient mode. Or we can say in current mindset, provide less-then-good solution to users. Alon. _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
