This document assumes you have read the general concept of the translation process. It explains what you need to do to add a translation of your own for some implementation.
To get the configuration from VeriNeC's XML format into a machine, two steps
are needed. First, an XSLT document will translate the configuration into a
format suitable for a service implementation. Some implementations of a service
might not support all features that can be expressed in the VeriNeC XML. For
those, a 'restriction' XSLT stylesheet can output warning messages for unsupported
features used in a configuration.
Finally, a distributor written in Java handels the XML document generated by
the translator XSL. If the translated document contains <result-file> tags, this
could typically be the cp or scp distributors to write the files.
For every new service implementation, you need to write the XSLT document to
translate the VeriNeC XML into a suitable format. The output must conform to the
configuration.xsd schema. If needed, you also construct the restriction XSLT
document, generating a document conforming to restrictions.xsd.
If you need to use a distribution method not yet supported (i.e. SNMP), you also
have to write a Java class implementing the IDistributor interface.
A repository implements how the XSLT for a service is found. The default (and only) repository is a file repository. It looks for files in a certain folder (see below) and if it does not find them there, tries to load them from the classpath as a resource. You can add your own XSL files according to the directory concept:
In the current working directory of the application (the directory where it is started from, for eclipse this is the root directory of the project), the repository looks for a folder named 'translation'. Inside that folder, there is a folder for each service type (ethernet, dns, etc.), containing the folders translators and restrictors. Inside the translators directory, a service implementation is placed with the name used in the XML document and the .xsl extension. So this makes us:
+translation/
|
+<service1-name>/
| |
| +translators/
| | |
| | +<translator1-name>.xsl
| | +<translator2-name>.xsl
| |
| +restrictors/
| |
| +<restrictor1-name>.xsl (if needed)
| +<restrictor2-name>.xsl (if needed)
|
+<service2-name>/
...
The distributor is used to handle a target like cp or scp. A distributor can
normally only handle a part of the tags in the configuration.xsd document.
(For example, the cp task only handles result-file tags.)
To find out which distributor to use, VeriNeC looks at the target of a service
and asks the IDistributorFactory for a suitable distributor. The
TranslatorModule uses the PropDistFactory, which is configured by the file
res/distributormap.properties within the classpath. It tells which class to load
for what target name (like cp, scp).
Write the IDistributor implementation for your needs and put it into the class path. Now you can simply edit the distributormap.properties and add for your target the full class name of your implementation.