The SDK is strongly based on code generation. The actual definition is done in an XML Schema Diagram (XSD) which specifies the objects, attributes, types, boundaries etc. This XSD is fed to a code generator that creates an interface library in various languages. The SDK includes examples on how to use the library.
The library has a prescribed interface in all languages, which is explained in the following diagram
At the core is an interface that consists of:
- reading strings with IVEF XML
- emiting objects generated from that XML
- boundary checking
- generating XML from the objects
Note: that the current Java implementation does not “emit” events yet. It requires the user to subclass the Parser class an overwrite the handle methods as apposed to listening to a particular event. This will change in the future
Layering
The SDK consists of 4 layers, each having there own release cycle. Updates in the data definition will trigger a release of the library which complies with the new version of the definition.
The tools layer has their own release cycle which can also trigger a new release of the library, which is compatible with the previous version (wire format) but may yield more functionality or performance.
Any update in the library will lead to an update of the examples since they demonstrate the workings of the library. Updates in the protocol description may also trigger new examples.
(as of 0.1.1 the examples are part of the library)
Documentation
Protocol Description
The protocol description is in development and the current draft can be found in the download section.
Data Definition
In the documentation section you can find the XSD schemes that define the interface. The XSD is also available as a pdf document
We use a version number based on major.minor.path patch releases fix only bugs, minor releases are compatible with minor effort, major releases contain complete overhauls. We have created a page with SVN Commands
Tools
xsd2code
The core of the SDK is generated by the xsd2code tool. This is a generic tool but developed and tuned especially for the IVEF format. It takes the XSD specification as input and generates classes that hold and verify the information as specified by the IVEF format. It also includes a XML generator in each class and and a generic parser that can parse XML and notify the user of new IVEF messages (based on the generated classes) (Read herehow to build the software)
The generated classes are half of the story. You will still need to obey the sequence of sending and receiving messages. That’s why we have created some sample software that shows basic handling of the sequences of both the server and the receiver.
tests
The library comes with a simple automated Test environment which is used to test if the library performs as it should. The Test framework is available for the Qt version of the library, but can easily be ported to the other libraries as well.
astyle
Coding style is enforced with the help of astyle –style=kr
Library
The library holds the generated source code, so each version of the library is depended on the version of the data definition and the version of the code generator that is used.
Examples
iListen
iListen is short for “IVEF Listener”. This is a simple example of a user program for connecting and obtaining data from an IVEF source. iListen also makes an excellent test tool.
ivef2kml
An example that can connect to an IVEF source, similar as iListen, and convert incoming data to Google’s KML format. The format is offered as a web service, which allows applications as Google Earth and Google Maps to connect directly to a IVEF source.
iSim
A ship simulator that generates objects (randomly) and outputs them in the IVEF format. This is designed as a coding example of the server side, but also serves as an excellent test tool. (Currently in alpha)