Am Mittwoch 04 Februar 2009 19:55:33 schrieb Alon Bar-Lev:
> We discussed this too many times, Andreas also discussed this with you.
> OpenCT provide supportive environment for drivers, common code for logging,
> common code for protocols, common code for device access etc...
> If you write a driver using IFD Handler API you need to reinvent the wheel.

hu? not sure what you refence here. ifdhandler api sucks, as every reader
needs to implement protocols like t=1 again and again.

but if we implement one ifdhandler that talks to many different readers,
or if we implement many ifdhandlers with one common code, then
we mitigated that problem.

> What you have:
> 1. PC/SC API - supported by you, nobody has any compliant.
it sure sucks (e.g. only blocking access to readers). but if you place
a higher logic on top (e.g. central daemon alla ms crypto api or mac os
X tokend), then this might be not a big issue any more.

> 2. CCID driver - supported by you, has the limitation of libusb and IFD
> Handler API.
well, I don't see a viable alternative.

> 3. Framework - threaded, complex, PC/SC specific which is what
> we discuss.

I don't see how you can support the same feature set with less complexity
(and without threadding too).
We discussed this too many times, Andreas also discussed this with you.
OpenCT provide supportive environment for drivers, common code for logging,
common code for protocols, common code for device access etc...
If you write a driver using IFD Handler API you need to reinvent the wheel.

still I whish you luck Alon for your project!

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to