openct already has a fci file, adding some information into it so gui tools can identify the result is not a bad idea I guess.
please don't use "card_reader", we already have trouble with people only knowing comptact flash / smart media cards / ... and being confused by what we call "smart card". so please use "smart card reader" and friends. or even better, throw in "iso 7816" somewhere, as that technical term is the best way to clearly say what we are talking about. I understand the distributions problems: they chose to ship the cyberjack utilities, and now need to live with the stupid design those have (direct access to the device). on the other hand I can't even blame them: while simple operations such as accessing a memory card should work well via pcscd, more complex operations such as "upload new firmware to card reader" will most propably never work with pcscd (guessing only, I'm no expert here). my personal recommendation is: * use libccid + pcsc-lite for all smart card readers and applications * yes, that means not using openct. we need to admit, that openct has no proper pin entry code for readers with display and pinpad. * yes, that also means not using the (most likely binary only?) code the vendor published. I'm pro open source here, sure. also I think distributions are much better off with one generic software, than they are with many vendor-specific incompatible solutions. also I want to point out, that people might want to use smart card readers for authentication. hal seems to be very gui-desktop centric, if I'm not mistaken? (people still seem to use /etc/fstab to mount there filesystems, and not a hal config file....) using udev was a huge pain for many years, everytime I thought "now it works", a few months later openct didn't work with the new udev. I'm sick of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal, and hal seems to work, I think it is best to take their advice and do that: use hal! I have too little clue about the further developments of hal and policykit and what kde and gnome do, so I can't comment on that. if anyone wants to walk into the opposite direction, write a daemon that monitors usb and then acts on any change, that is fine with me - I think pcscd does exactly that? not sure. it would have saved me much, much time, if I had choosen that road many years ago. but at that time I thought it would be better to let the kernel do that, and get "signals" from the kernel (e.g. hotplug interface, later via udev). but now that hal+udev+kernel seem to work fine, I hope we can keep using them. Regards, Andreas _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
