Michael Traut
2013-07-16 15:03:22 UTC
The initial release for an alternate javax.smartcardio provider is now
included in https://github.com/intarsys/smartcard-io/.
This was an interesting task that we used as a chance to review & cleanup
some API's in our basic implementation. And, unbelievable, there are still
"corner cases" that had failed up to now. Another interesting aspect was
the mapping from out "event driven" API to the blocking API of smartcardio
(and i must say i prefer the event driven one). So, even if nobody may care
of this lib, we've already gained...
For the smartcardio implementation itself we have the following state:
* Intended differences
** dedicated PCSC context for terminals, terminal and card (true
concurrency)
** waitForChange(timeout) semantics improved(?), state change is reset even
in case of timeout
** reader insertion is handled, too
** no finalizer for card!
* Open design questions
** "exclusive" card access is NOT restricted to a Java thread. We found no
technical reason for this constraint. imho this makes handling of shared
and pooled resources ugly. Next to "Only one PSCS context" this would be my
top level reason *not* to use smartcardio. Any opinions?
** "connect" always returns the identical {@link Card} object. This is why?
This implementation currently opens a new shared connection. If we revert
to the spec, i'd at least expect some kind of reference counting. Opinions?
* Todos
** no channel support yet
** implement "GET RESPONSE"
** no permission checks so far
** review exceptions to be standard compliant (IllegalStateException)
We'd be very happy if someone around wants to use and verify the lib in
their own project (as we do not rely on smartcardio...)
The next step for this project will be to "clean up" the proprietary
smartcard abstraction layer and implementation that we use ourselves (this
may result in minor API changes).
Regards, Michael Traut
included in https://github.com/intarsys/smartcard-io/.
This was an interesting task that we used as a chance to review & cleanup
some API's in our basic implementation. And, unbelievable, there are still
"corner cases" that had failed up to now. Another interesting aspect was
the mapping from out "event driven" API to the blocking API of smartcardio
(and i must say i prefer the event driven one). So, even if nobody may care
of this lib, we've already gained...
For the smartcardio implementation itself we have the following state:
* Intended differences
** dedicated PCSC context for terminals, terminal and card (true
concurrency)
** waitForChange(timeout) semantics improved(?), state change is reset even
in case of timeout
** reader insertion is handled, too
** no finalizer for card!
* Open design questions
** "exclusive" card access is NOT restricted to a Java thread. We found no
technical reason for this constraint. imho this makes handling of shared
and pooled resources ugly. Next to "Only one PSCS context" this would be my
top level reason *not* to use smartcardio. Any opinions?
** "connect" always returns the identical {@link Card} object. This is why?
This implementation currently opens a new shared connection. If we revert
to the spec, i'd at least expect some kind of reference counting. Opinions?
* Todos
** no channel support yet
** implement "GET RESPONSE"
** no permission checks so far
** review exceptions to be standard compliant (IllegalStateException)
We'd be very happy if someone around wants to use and verify the lib in
their own project (as we do not rely on smartcardio...)
The next step for this project will be to "clean up" the proprietary
smartcard abstraction layer and implementation that we use ourselves (this
may result in minor API changes).
Regards, Michael Traut