Hi,
On 13.10.2016 20:23, Sylvain Joyeux wrote: > 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. How do dynamic properties replace dynamic creation/destruction of ports? If the example of the server assinging ports to each client is one that we intend to cover, maybe you could clarify with this example. > > 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). Dynamic ports are then currently possible to be created once (if any) and not destroyed/cleaned up? Raúl > > Sylvain > _______________________________________________ > Rock-dev mailing list > Rock-dev@dfki.de > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev -- Raúl Domínguez (M.Sc.) Space Robotics Besuchsadresse der Nebengeschäftsstelle: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Postadresse der Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany Tel.: +49 421 178 45-6617 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: raul.doming...@dfki.de Weitere Informationen: http://www.dfki.de/robotik ----------------------------------------------------------------------- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973 Steuernummer: 19/673/0060/3 _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
