Open eCard

h1. 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.

h1. Types of add-ons

*TODO*

h1. 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:

<pre>

<?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>

</pre>

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* ...