Thank you for the link. I only had a quick look, so maybe my remark's are invalid...
I think the dependency on a native wrapper is a bit annoying. The declarative strategy with JNA, together with lots of precompiled binary platforms was very comfortable for us. The PCSC wrapper is not available self-contained. You should expect some effort separating it from OCF.. On Fri, Jul 5, 2013 at 2:42 PM, Andreas Schwier < [email protected]> wrote: > OCF also has a native PC/SC driver contributed by IBM. > > The code is at http://www.openscdp.org/ocf/index.html > > Andreas > > > On 07/05/2013 02:31 PM, Frank Marien wrote: > > > > On 07/05/13 14:04, Ludovic Rousseau wrote: > >> 2013/7/5 Michael Traut <[email protected]>: > >>> We already have a platform independent native adapter to pcsc and > pcsc-lite. > >>> We developed this before smartcardio popped up and never switched > because of > >>> the limitations of smartcardio - it is used in our (closed-source) EAL > >>> certified signature application. > >>> > >>> We'd like to donate this lib if anybody is interested... > >>> > >>> The runtime stack consists of > >>> > >>> - JNA runtime > >>> - intarsys native memory model (as we dislike the JNA > abstractions...). This > >>> is already BSD licensed (via jPod on SourceForge) > >>> - intarsys PCSC wrapper (including all SCARD features WE needed so far) > >>> - intarsys Card abstraction. A small layer on top of PCSC, with some > >>> features we found very useful in the years. > >>> > >>> The pro is without doubt that we use this for years, fixed small > "bugs" with > >>> every version of win*, 32 and 64 bit, Mac and Unix derivates, for > every card > >>> reader explicitly supported and poorly programmed by the provider... > There > >>> have been so many incompatibilities to work around we simply can't > list... > >>> > >>> For some, the downside may be that we do NOT plug in smartcardio and > have > >>> different abstraction for terminal/card/connection. The "card" > abstraction > >>> (while not required, but really recommended) is quite strict and on the > >>> exact opposite of smartcardio. Every card terminal and every card > connection > >>> comes with its own context... > >>> > >>> If appropriate, make some suggestions on where to host the lib.... > >> Great! > >> > >> I would propose to host the lib at github.com, unless your are more > >> familiar with another system. > >> > >> Or if the library has a really low activity we could host it in the > >> contrib/ directory of the pcsc-lite project at > >> http://anonscm.debian.org/viewvc/pcsclite/trunk/contrib/ > >> > >> The real question is: do you propose yourself as the project > leader/maintainer? > >> > >> Bye, > >> > >> -- > >> Dr. Ludovic Rousseau > >> > >> _______________________________________________ > >> Muscle mailing list > >> [email protected] > >> > http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com > >> > > Second that "Great!" from Dr Ludovic. I've been looking into > > implementing this and I figure it has taken a lot of work to get and > > keep working right. It would save others a lot of work if you would > > share that. de.intersys.opensource['karma']++ :-) > > > > _______________________________________________ > > Muscle mailing list > > [email protected] > > http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com > > > > > -- > > --------- CardContact Software & System Consulting > |.##> <##.| Andreas Schwier > |# #| Schülerweg 38 > |# #| 32429 Minden, Germany > |'##> <##'| Phone +49 571 56149 > --------- http://www.cardcontact.de > http://www.tscons.de > http://www.openscdp.org > > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com >
_______________________________________________ Muscle mailing list [email protected] http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
