2009/2/6 Alon Bar-Lev <alon.bar...@gmail.com>: > 3. CCID driver > > The CCID driver will be migrated to the new framework, dropping the libusb > usage > and use USB directly, this way it would be more efficient and can use as many > feature as available in the operating system.
Are you talking about the OpenCT CCID or my CCID driver? I ask because I need a working CCID driver for step 5. But a mostly working CCID driver may be enough. > 6. My tasks > > While you busy with (5), I will migrate the OpenCT's CCID driver into the new > framework. The OpenCT CCID is much closer to this model, so it would be > the easiest to to migrate and have the first working driver. > > I will also migrate eToken driver as it is simple and allow to demonstrate a > simple driver. > > Implement the IFD Handler API reader driver as you requested. One thing I > don't understand, if you state that only CCID compliant readers are available > and all other drivers are unmaintained, why support this interface. Anyway, > as we discussed unless you release me from this obligation I will implement > a reader driver that use IFD Handler API in order to access legacy drivers. We don't need this interface to write _new_ drivers (you said it was too complex) but to support existing drivers and readers. And, yes, this is a mandatory piece if you want your solution to be accepted and deployed in existing systems. > 10. Joint tasks > > Phase out pcsc-lite and OpenCT. If you want to have an easy acceptation by users you should think the new framework as an evolution of an existing solution. And ideally we should reuse an already known brand name. That is why I propose to call it pcsc-lite v2.0 and propose to use the same hosting service as pcsc-lite (alioth). You should think of the project as a drop-in replacement of pcsc-lite 1.x for users: same PC/SC interface for the applications and same IFDHandler interface for the installed drivers. The project will also have many new features of course. >> I propose to start a pcsclite/branches/2.0 or something similar on >> Alioth pcsc-lite project. >> >> If needed I can ask to convert the pcsclite project to use TRAC on Alioth. > > In the spirit of cooperation, why not manage this project under the > OpenSC-Project.org > umbrella? It will send better message for users. Why would that send a better message? Better than what? Can't we cooperate if we use Alioth? > Anyway, we will need at least the following repositories: > 1. libscreader > 2. pcsc-lite or pcsc-screader > 3. screader-driver-ccid > 4. screader-driver-etoken > 5. screader-driver-etoken64 > 6. screader-driver-ifdh > 7. screader-driver-rutoken > <etc> We need a source code repository with sub-projects. On alioth we already have trunk/PCSC, trunk/Drivers, trunk/Drivers/ccid, etc. I don't think that having a different/independent repository for each sub project is useful/needed. Do we have to split libscreader and pcsc-screader? If we do then we will have to keep the interface between them stable. If it is the same project we can easily change the interface since that would be an internal interface (with no stability guarantee and then more freeness). If you want to have an openct-screader it can also be included in the same project using the same "internal" interface. For reason I already noted above (drop in replacement) the screader-driver-ifdh should also be included in pcsc-lite v2.0. Bye -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
