[Rock-dev] Dynamic Ports in Task Model

[Sylvain Joyeux]

Dynamic ports are indeed the black sheep of orogen ...

Now, I believe that wanting to put the link between configuration and
dynamic ports inside orogen itself would be counter-productive. I
always limited orogen's expressive power in order to keep it usable
(too many models would not be picked up by developers in any case,
and/or would make them hate the tool). Moreover, this "link" is very
complex.

The usage of operations to create/remove ports is an anachronism. With
dynamic properties, we should make away with this practice. This
leaves us with properties.

In any case, putting the dynamic ports to be created as a property
does *not* add any descriptive power to the model. It's virtually
duplicating the introspection interface: you tell the component what
to create and are sure the ports will exist. You have no guarantee
that these ports will actually be used, therefore removing the current
behaviour that one can reasonably assume that if a port was created,
it's because it will be used.

oroGen is *not* the only source of models in the system. If you use a
model-less integration layer, then the orogen models are just unused
(or barely used). If you use Syskit, it already has the descriptive
power (in its own language) to deal with that link, in a way that
oroGen should not have (unless you want to make oroGen an extension of
Syskit). If you want to use another integration tool, describe it into
its own language.

So far, I personally only was planning on generating
creation/suppression methods and lifecycle handling for dynamic ports,
e.g.

   dynamic_ports 'joints_in', type: '/base/samples/JointState', pattern: /_in$/

would generate

    OutputPort<...>* createJoints_inPort(std::string const& name);

and the relevant lifecycle handling (e.g. clearing dynamic ports on cleanup).

Sylvain