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 _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev