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