Hi Dimitri,
Current AppletManagerCardService interface may seem to be designed for
JavaCard and not suitable for MultOS, actually you can use it for both.
first let me explain what register means; with JavaCard platform, the
loading (installation) of an applet and its activation (making it
selectable) are two different steps while on Multos card, the OS lets you
select your application once just loaded.
the aim of the installApplet() method is so to provide a way to store the
byte-code (or whatever-code) of your application into card's EEPROM, and
the registration allows application instanciation and makes the OS
dispatcher aware of that instance (creating an entry into an "on-board
registry").
now how to use the AppletManagerCardService, obviously if you implement
your own prototype, or if you provide a service implementing that interface
with empty methods and addind new ones, you won't benefit of OCF scheme
(factoring, service registration, ...), you should so implement the three
defined methods.
you can easily follow these rules and success in your implementation just
giving more (some) sense to the parameters these methods receive:
installApplet except an AppletCode instance; this class is defined as an
empty abstract class, you so have to implement an actual Multos AppletCode
meaning a class that defines how a Multos application is coded; such class
will contains (manages, ...) a stream connected to an alu file and the
certificat used for loading, indeed both are need for installApplet method
(certif. transmitted with INS 12h and alu file loaded with INS 24h).
Multos does not require application registration and registerApplet() seems
meaningless, in fact you should use this method to keep (card & applet
management system may be usefull) a link between applications (known by
their AID) and installation/removal process; you should use this method to,
for instance, store in a database the deletion certificate (as well as
memory used by that application) linked with that AID.
finally, you'll implement removeApplet() to get back the deletion cert.
from the base using the AID and to perform actual deletion of application.
(INS 18h transmitting cert.).
generic applet loading mechanism has a constraint, services offered by the
AppletManagerCardService interface is not a limitation, nor obviously the
way a service implementing that interface will be selected (factoring is
efficient enough) but, of cause, the availability of code for the used
card; any other services make total abstraction of the actual card, an
specific implementation of a service must take all card characteristics
into account, when you want to use generic applet loader, you should also
have all necessary AppletManagerCardService implementations (Multos,
JavaCard, ...) but also all applet codes (alu file, cap file, ...) .... i
guess (hope) loader have not to be generic !
Sylvain.
At 16:11 28/06/00 +0200, Dimitri Langlois wrote:
>I would like to make a kind of AppletManagerCardService for Multos, but this
>interface doesn't seem adapted for it. With Multos, each time you load or
>delete an application, you have to provide a certificate, and neither the
>registerApplet (What is applet registration, by the way ? Do you have to
>register the applet after having installed it ?) nor the removeApplet
>methods are able to take a certificate parameter.
>
>What should I do ? Wait for the next version of OpenCard, which will perhaps
>take this is consideration (but I guess I can wait for long), or just make a
>"standard" service, with all methods taking all the parameters I want ?
>And in fact, what are the benefits of using the AppletManagerCardService
>interface ?
>
>Regards,
>
>Dimitri.
---
> 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.
