<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Morning,<br>
      <br>
      You can "missuse" add_base_implementation_code for you requirement
      and completly manually define the method.<br>
      Otherwise you would need to extend orogen (in detail the method
      add_base_method) but keep backward compatibility.<br>
      <br>
      Best,<br>
      Matthias<br>
      <br>
      On 02.04.2015 10:57, Christian Rauch wrote:<br>
    </div>
    <blockquote cite="mid:551D0473.5030405@dfki.de" type="cite">The
      orogen plugin that I have currently in mind is for providing the
      state serialization capability to all tasks in general if selected
      in the orogen file; not only to tasks were we have no influence on
      (like public tasks). The orogen plugin should provide an easy way
      to create the operations for the tasks, such that all serializable
      tasks share a common interface. This serialization should also
      work with non typekti types if the serialization is implemented
      with e.g. boost-serialize.
      <br>
      <br>
      Regards,
      <br>
      Christian
      <br>
      <br>
      Am 02.04.2015 um 10:49 schrieb Janosch Machowinski:
      <br>
      <blockquote type="cite">Am 01.04.2015 um 19:09 schrieb Sylvain
        Joyeux:
        <br>
        <blockquote type="cite">
          <blockquote type="cite">Any suggestions?
            <br>
          </blockquote>
          This is completely unsupported in orogen.
          <br>
          <br>
          If you describe the complete use-case (i.e. what you are
          trying to
          <br>
          do), I might be able to suggest another way ...
          <br>
        </blockquote>
        The complete Use-Case is a full dump of our component network.
        <br>
        We got the scenario, that we have a robot operation with a big
        <br>
        delay in the network communication. To deal with this, the robot
        <br>
        component network, including the INTERNAL state of the Tasks
        <br>
        should be dumped and transmitted. The dump is then used in
        <br>
        the control station, to build up a component network which can
        <br>
        be used for a simulation of the robot.
        <br>
        The dumping of the network itself should be covered by the
        <br>
        introspection ability, which I am working on. The part of
        Christian
        <br>
        is to find a good way to dump the internal state of the Task.
        <br>
        <br>
        For our 'own' tasks, this is straight forward, as we can
        implement
        <br>
        some interface for this. Our problem is with common tasks. For
        <br>
        now we came up with the idea, to subtask them, and dump the
        <br>
        protected / public members out.
        <br>
        To make out life easier we were thinking about an orogen plugin,
        <br>
        that would do the subtasking, and the code for the dumping of
        <br>
        the members (member names given in the orogen file). Note,
        <br>
        we assume, that the typekits for the member types are present.
        <br>
        Greetings
        <br>
              Janosch
        <br>
        <br>
        <blockquote type="cite">
          <br>
          Sylvain
          <br>
          _______________________________________________
          <br>
          Rock-users mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:Rock-users@dfki.de">Rock-users@dfki.de</a>
          <br>
          <a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users</a>
          <br>
        </blockquote>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Rock-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-users@dfki.de">Rock-users@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
 -- 
 Matthias Goldhoorn
 Unterwasserrobotik
 
 Standort Bremen:
 DFKI GmbH
 Robotics Innovation Center
 Robert-Hooke-Straße 5
 28359 Bremen, Germany
 
 Phone: +49 (0)421 218-64100
 Fax:   +49 (0)421 218-64150
 E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:robotik@dfki.de">robotik@dfki.de</a>
 
 Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.dfki.de/robotik">http://www.dfki.de/robotik</a>
 -----------------------------------------------------------------------
 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 
 -----------------------------------------------------------------------


</pre>
  </body>
</html>