Hi Sylvain,
see comments below.
>the EventGenerator generates the right event and CardTerminalRegistry
>handles finely the connected readers ... and the CardServiceRegistry gives
>the right service if card are "inserted or removed" but there are some
>problems when the card changes, meaning for instance when its ATR or its
>contents changes after running a specific card service that doesn't
>withdraw itself the card.
>in such case, because ATR change is not handled by
>Pcsc10CardTerminal.internalReset and because CardServiceScheduler caches
in
>a hashtable the service returned for a specific CardType, it is not
>possible in a CardServiceFactory class based instance to check and return
>the actual services supported by the card.
The card type is intended to identify the type of the card itself, e.g.
IBM MFC 4.21, GeldKarte, GemXPresso, GPK8000 ... Thus the card type does
not
change when the ATR of a card is changed.
Adding applications to a card is a different story. When you want to use
application dependent services, you should use the package
opencard.opt.applet
as a basis. Application specific services should be derived from the class
applet proxy.
An AppletProxy Factory for a Visa OpenPlatform JavaCard would for example
query the application ids of the applets on the card and offer to
instantiate
the appropriate services for the known subset of applets.
>such problems if they occur after applet loading on multi-applicative
>smartcards are may be not the first concern of OCF, but the same will be
>true to manage a "Read Record" card service for an ""old"" smartcard, one
>can decide to not return such service if the specified file does not
>contain any record when the request is sent to his factory but will
respond
>positivly after "Append Record" issuance.
Best regards,
Thomas
Thomas Schaeck
Pervasive Computing Division - Extended e-business Solutions, EMEA
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
Sylvain Ferey <[EMAIL PROTECTED]> on 28.02.2000 23:37:01
Please respond to Sylvain Ferey <[EMAIL PROTECTED]>
To: Thomas Schaeck/Germany/IBM@IBMDE
cc: [EMAIL PROTECTED]
Subject: Re: [OCF] OCF 1.2 CardTerminalRegistry.setPollInterval() -
deprecated? Alternative?
Hi Thomas,
the EventGenerator generates the right event and CardTerminalRegistry
handles finely the connected readers ... and the CardServiceRegistry gives
the right service if card are "inserted or removed" but there are some
problems when the card changes, meaning for instance when its ATR or its
contents changes after running a specific card service that doesn't
withdraw itself the card.
in such case, because ATR change is not handled by
Pcsc10CardTerminal.internalReset and because CardServiceScheduler caches in
a hashtable the service returned for a specific CardType, it is not
possible in a CardServiceFactory class based instance to check and return
the actual services supported by the card.
such problems if they occur after applet loading on multi-applicative
smartcards are may be not the first concern of OCF, but the same will be
true to manage a "Read Record" card service for an ""old"" smartcard, one
can decide to not return such service if the specified file does not
contain any record when the request is sent to his factory but will respond
positivly after "Append Record" issuance.
thank for any comments,
best regards.
Sylvain Ferey.
At 19:10 27/02/00 +0100, [EMAIL PROTECTED] wrote:
>Hello,
>
>for OCF 1.2 we introduced a clear separation between terminal registry
>functions and event generation, by splitting the monolithic class
>CardTerminalRegistry class into a remainder and the new class
>EventGenerator. The CardTerminalRegistry is now responsible for
>registration of card terminals and the EventGenerator is responsible for
>polling card terminals and generating appropriate events when cards are
>inserted or removed.
>
>Right now, the CardTerminalRegistry still has some old functions that
>belong to the classes former event generation responsibility. We only
>deprecated them instead of removing them to avoid immediately breaking
>code. Currently, these deprecated methods of CardTerminalRegistry are
>mapped to the appropriate methods of EventGenerator. They will most
>probably be removed in the next release of OCF.
>
>Therefore, you should now call the method
EventGenerator.setPollIntervall()
>instead of the deprecated method CardTerminalRegistry.setPollIntervall()
in
>your applications.
>
>Best regards,
>
>Thomas
>
>Thomas Schaeck
>Pervasive Computing Division - Extended e-business Solutions, EMEA
>Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
>[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
>Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
>Boeblingen, Germany
>
>
>"Tom McKearney" <[EMAIL PROTECTED]> on 24.02.2000
>22:01:13
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
