[Rock-dev] Dynamic Ports in Task Model

[Raul Dominguez]

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 at 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.dominguez at 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