Hello, On Saturday 07 February 2009 14:23:30 Ludovic Rousseau wrote: > 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.
The final goal is to have a full featured CCID drivers (devices,PINPAD, events). We can do this either way. > 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. OK > > > 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). Martin Preuss got it right. The PC/SC API will be provided by one client of the new reader framework. So keeping the name for the client part is OK, but the whole framework is a different component which is unrelated to PC/SC, and may be used by other APIs without dependencies in PC/SC implementation. > 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. Not exactly... The PC/SC client library would be drop-in replacement, this is a must. I guess the IFD readers would need a different configuration, as the "XML" should be converted into hotplug statements, and the reader instance should locate the shared library to load. (Explicit model vs. implicit model). > >> 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? We can cooperate at any place. Apart of a great reader framework I want to unite as all into a single place, in which we can marked open source hardware cryptography. This will send a good and coherent message to users, and indirectly also help as focus. > 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. We need a stable interface for application API , reader client and reader drivers. Application API: PC/SC Reader client: libscreader Reader drivers: libscreaderd > Do we have to split libscreader and pcsc-screader? I wish to separate between a single Microsoft oriented application API and the reader framework. This will enable other application APIs to use the same framework without conflict. It will also allow application to communicate with reader drivers directly, and perform various of extra operations, such as loading firmware or initialize. > If we do then we will have to keep the interface between them stable. This is the plan. > 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). I think that providing a clean interface between the components is the key for success. As it will also force a clean PC/SC implementation. > If you want to have an openct-screader it can also be included in the > same project using the same "internal" interface. I thought of using the stable API to implement some other application APIs, and maybe convince developers who accessed the reader directly to use the new infrastructure (GnuPG, coolkey etc). > > For reason I already noted above (drop in replacement) the > screader-driver-ifdh should also be included in pcsc-lite v2.0. > OK. What do you think about the other tasks/assumptions? Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
