[Rock-dev] Dynamic Ports in Task Model

[Jakob Schwendner]

Since I started this, I should probably also reply :)
I would like to avoid any discussion on the general merit of dynamic ports. 
I think it was understood by most what I intended with the proposed change. Just going a bit further with what Sylvain already hinted he would like orogen to generate: the helper function for generating the dynamic ports, and a general contract on the lifecycle (e.g. when can the ports be generated.)
That orogen itself is not capturing the entire model is fine with me. But the more self-descriptive it is, the better. 

Just a few things:
- I don't see that generating new ports in the RUNNING state is necessary anywhere. Restricting it for the transition to CONFIGURED is not harmful but only helpful.
- How it works now with e.g. the joint_dispatcher is that you create a configuration, if this configuration is not consistent or invalid, you don't transition to CONFIGURED.
- The change I proposed would do the same thing: The configuration for the joint_dispatcher (and imho any other module) would just be expressed in a slightly different manner.
- Yes, only at run-time would you know if it worked, unless you have another model and validation tool sitting on top.

What you gain though, is
a) a more streamlined way of how to handle dynamic ports in the code
b) a better generic knowledge on the structure of your task
c) a cleaner interface for your model validation to hop onto
d) a generic and natural way for task introspection

One task that was mentioned that would be more complex is the one mentioned by Martin, the robot_frames. 
Instead of parsing a URDF in task, you would put this into the configuration procedure for your task. I think both syskit and orogen.cpp know how to do this, at least with the transformers, and could probably do the same with robot_frames.

Cheers,

Jakob