Release Notes 0.7

Support for the new iWSN API 2.3

Testbed Runtime now supports the new iWSN API in version 2.3.

It supports all methods except of the newly introduced WSN.setChannelPipeline() and WSN.getSupportedChannelHandlers() which are targeted for 0.7.1. These methods are currently implemented as empty stubs and will throw an exception if you try to call them.

New Issue Tracker and Wiki

This release was the last release that used the old trac issue tracker and wiki under https://www.itm.uni-luebeck.de/projects/testbed-runtime/! We are now in the progress of moving all issues and the Wiki to github in order to have all source, documentation and downloads in one place. This basically makes it easier for everybody to file issues or contribute documentation.

All issues prior to and including version 0.7 will stay at the trac issue tracker for documentation purposes. All tickets target for a version greater or equal to 0.7.1 will be hosted at the github issue tracker.

Changes for Clients (Testbed Users)

Lets start with the good news:

• The backend implementation now bundles messages on delivery as introduced with iWSN API 2.2. Therefore, message delivery for Web service based clients is now much faster!
• The backend implementation will now deliver all queued messages before shutting down when an experiment ends. In the older versions, if message delivery to the clients' Controller interface was slower than messages were generated by the nodes this resulted in the messages being dismissed at the end of the experiment. For the next version we plan to integrate a persistent message queueing that allows to queue up more messages than in memory, thereby allowing more messages per second from the nodes.
• The Experimentation Scripts assembly contains some new scripts for experimentation.

Now for the not so good news: Package names of the imported WISEBED APIs have changed! Therefore, all custom scripts based on the Scripting Client need to be updated! This is basically a search and replace operation. Simply replace the old package names with the new package names as listed below:

Old Name	New Name
eu.wisebed.testbed.api.snaa.v1	eu.wisebed.api.snaa
eu.wisebed.testbed.api.rs.v1	eu.wisebed.api.rs
eu.wisebed.testbed.api.wsn.v22	eu.wisebed.api.wsn eu.wisebed.api.controller eu.wisebed.api.sm eu.wisebed.api.common depending on where the corresponding type was defined in the WSDL and linked XML schema files

Changes for Testbed Providers

There's only one small thing that I can remember right now: As the module tr.runtime.cmdline was renamed to tr.iwsn-cmdline the file name of the jar changed. So please update your wrapper configuration file conf/tr.iwsn.conf of the iWSN assembly accordingly:

...
wrapper.java.classpath.1=../lib/tr.iwsn-cmdline-{TR_VERSION}-onejar.jar
...
wrapper.app.parameter.1=../lib/tr.iwsn-cmdline-{TR_VERSION}-onejar.jar
...

If something occurs to you please file an issue.

Changes for Developers

Module Renaming and Removing

Several modules were renamed to provide more meaningful names and a more meaningful overall module strucutre. Heres a (hopefully complete) list:

Old Name	New Name
tr.runtime	tr.overlay
tr.runtime.socket-connector	tr.overlay-socketconnector
tr.runtime.stats	tr.overlay-stats
tr.runtime.cmdline	tr.iwsn-cmdline
tr.runtime.portal	tr.iwsn-service
tr.csv2config	tr.iwsn-csv2config
tr.runtime.wsn-app	tr.iwsn-deviceapp

Also, some were removed:

• Removed logcontroller and messagestore-api module as they were outdated and unused
• Removed module tr.runtime.xml-testbed-factory and moved its functionality to tr.iwsn-cmdline module

Branching Strategy

I would love to have a convention on how branching should be done in the future. Therefore, I started following the "git-flow" branching philosophy that helps keeping master stable (only for releases!) and keep development of the next release, features and hotfixes separate. Also, git-flow has tool support. Check out this excellent blog post that was the inspiration for the command line tool. Also, there's a tutorial screencast if you want to see it in action.

Even if you don't want to use the git-flow tool for any reason, please never develop inside the master branch but only inside the develop branch which is used for the features and bugfixes of the next release or specialized feature branches and send me pull requests to merge your stuff into develop for the next release.

Lots of Tickets Fixed

For the (close to) full list of issues that were fixed for this release, please take a look at the tickets for milestone 0.7.