Add-on System¶

This section describes the add-on system from the perspective of a developer.
The implementation of the add-on system is located in the maven module with the group Id org.openecard and the artifact Id addon.
All classes are in a sub namespace of org.openecard.addon. The module is divided into the following five packages:

• org.openecard.addon
  In this package are the main classes of the add-on system, for example the AddonManager or the different AddonRegistries.
• org.openecard.addon.bind
  This package includes all classes representing the interface between an addon and a specific binding. That is to say, here are the classes needed to convert a specific request, for example a HTTP request that arrives via the localhost binding, into a generic request, which is independent from binding and vice versa for the response.
• org.openecard.addon.ifd
  In here are the classes that specify the interface for an IFD protocol and the factory to instantiate such a protocol.
• org.openecard.addon.manifest
  This package accumulates all classes needed to convert (automatically) between the XML represantation of the add-on description and it's java object pendants.
• org.openecard.addon.sal
  In here are the classes that specify the interface for an SAL protocol and the factory to instantiate such a protocol.

Types of add-ons
TODO¶

Add-on development¶

This section describes the steps to take when developing an add-on.
As first step a new XML file called Addon.xml in the META-INF directory of the project should be created and the fields that describe the general part of the add-ons can already be filled.
An example file for a PIN Management addon could look like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AddonBundleDescription>
    <ID>PIN-Plugin</ID>
    <Version>1.0</Version>
    <About />
    <License />
    <LocalizedName xml:lang="DE">PIN Verwaltung</LocalizedName>
    <LocalizedDescription xml:lang="DE">Verwaltung von PIN/ PUK und gegebenenfalls anderen Geheimnissen der Chipkarte.
    </LocalizedDescription>
    <LocalizedName xml:lang="EN">PIN Management</LocalizedName>
    <LocalizedDescription xml:lang="EN">Management of PIN/ PUK and possibly other secrets of the smart-card.</LocalizedDescription>
    <Logo>images/logo.png</Logo>
    <ConfigDescription />
    <BindingActions />
    <ApplicationActions />
    <IFDActions />
    <SALActions />
</AddonBundleDescription>

As can be seen, some fields can be localized. That fields are: LocalizedName, LocalizedDescription and About
The next step is to think about what actions should be offerd by the add-on and of what type these actions are.
For the PIN management example there are two actions. An action to change a PIN and a second action to unblock a PIN.
These actions are not of type ProtocolPlugin nor AppPluginAction, but of type AppExtensionAction, as they expand the function of the "Open an e-card app" independent from a binding or protocol.
TODO ...