On Thursday 06 December 2001 16:31, Dr S N Henson wrote: > David Corcoran wrote: > > It is possible for other cards to be supported through this interface > > such as memory cards and other cryptographic cards such as the GPK cards > > as long as they follow the same API and behavior scoped out by the > > MuscleCard client side API document. > > I'm interested in the possibility of using GPK cards for this. However > at first sight the GPK commands don't readily map onto the MuscleCard > client side API. > > For example AFAICS there isn't any way delete an object unless you > emulate it creating a big transparent file full of emulated objects but > then there are problems with getting the ACLs working.
Actually this is very similar to what we were doing for KDE 3.0 as well. I was unaware of this work and we were developing a similar system using shared libs loaded on demand for "card implementations". All in C++ using KDE classes though. I'm wondering if maybe we should abandon that or rework it to use this now. I am working with GPK cards and the other person is using GSM cards. We wanted to implement a very abstract architecture so that KDE applications could use smartcards without having to know the details of them. In particular, this would be used for storage, SSL certificates, and KDM login. Would it make sense for us to make a KDE friendly wrapper around this code instead? -- George Staikos *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
