One thing, which was on the back of my mind for a while was that at the
moment, the task model that is given by orogen is not completely explicit.
This is because of the dynamic ports. Effectively, because of the ability to
generate dynamic ports at any time, a task has an implicit model, which in
my opinion breaks with the general design principle of Rock for having
explicit models. The dynamic_output_port statement tries to put some order
in it, but is not really sufficient.
Currently, the shape (e.g. the input/output ports) of a task depends on the
configuration (and I guess even sometimes on operations that are called),
but in a way that is only known to the component. To use the model in e.g.
syskit or orocos.cpp, this behavior has to be mirrored on the model level.
I was employing the idea of model templates for a while, but this would be
fairly involved to implement.
Thomas had a good idea, which would be very simple, and would make
- You are not allowed to generate dynamic ports on your own in a task
- If either dynamic_output_port or dynamic_input_port exist, a property
called dynamic_ports is created
- This property includes a list of name/type pairs
- The orogen generated code would generate the ports from the dynamic_ports
property in the configure phase.
In this way, the complete model would be known already at modelling time, in
a generic way that needs no specific handling of certain tasks.
Please let me know of some negative examples, where this would not work.
Rock-dev mailing list