<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/16/2013 04:18 PM, Chris Mueller
wrote:<br>
</div>
<blockquote cite="mid:5194EACE.6090800@dfki.de" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
* I've introduced a new Job class, that should bind all necessary
information (ActionModel, ActionArguments, Task instance, ID)<br>
together. One point i'm currently not satisfied is the
representation of the running task instance which is currently a
Roby::Task<br>
retrieved from a prepare_action command. In the current
Roby::Interface class a PlanService is created from the Roby::Task
instance,<br>
that seems actually more appropriated. (I guess its some kind of
visitor representation that always hold the current active<br>
task for an action within a plan. Don't know, if this concept is
actually introduced for the RemoteInterface or also used for other
purposes.<br>
However, maybe Jobs and PlanServices could be also merged together
into a single class). <br>
</blockquote>
One major point of this refactoring was to use the tracking already
done by the Roby plan. It includes most of the information: the only
thing missing is the job ID, which could be added to Actions::Task.<br>
<blockquote cite="mid:5194EACE.6090800@dfki.de" type="cite"> * Class
Interface holds now all requested jobs in a Array and should be
the central point for managing<br>
the runtime behaviour of actions (Jobs). </blockquote>
The authoritative list should be the plan, not the interface.<br>
<blockquote cite="mid:5194EACE.6090800@dfki.de" type="cite">Each
Robot.action_command! should use Roby::Interface for requesting <br>
an action execution.</blockquote>
If all the tracking is done by the Roby plan, no need to do that.<br>
<blockquote cite="mid:5194EACE.6090800@dfki.de" type="cite">*
InterfaceProxy and RemoteInterface can be seen as the bridge
between two machines and should implement the communication via
sockets or another RMI<br>
Interface (Protocol, Data Serialization, Marshalling/Dumping,
etc.). Like Sylvian proposed, the InterfaceProxy is some kind of
server, that dispatches<br>
messages between RemoteInterface and the JobInterface. I'm
currently struggling if we should create several independend proxy
instances for each Interface <br>
instance or use a single instance that properly syncronize the
access from several remote interfaces. I guess i would favour some
kind of 1-N solution. That <br>
would move the code for syncronization concurrent accesses into
the proxy.<br>
</blockquote>
Idem here, since the interface(s) only access information within the
Roby plan, you only have to use synchronized access to it, which is
can already be done with plan.engine.execute { }<br>
<blockquote cite="mid:5194EACE.6090800@dfki.de" type="cite"> <br>
* Roby::Interface should never have some code for remote
communication stuff. <br>
<br>
I've currently left the decision open for the using communication
layer in order to specify first the central components and not
messing<br>
up the code with communication related stuff. Are there any
preferences which layer to use? (I'll will look further into some
ruby implementation<br>
within the next days). Because of this i also ignored all DRb
stuff within the old interface.<br>
</blockquote>
No real preference. Just not DRb. However, so far, it would be
better to continue using Marshal.dump/Marshal.load to do the
marshalling as there is a native support for that in Roby.<br>
<blockquote cite="mid:5194EACE.6090800@dfki.de" type="cite"> * The
old interface inject at runtime a GatherException module to the
Roby.engine, which forms some kind of Observer-Pattern and opens<br>
registration facalities for other instances with an Array of
Strings. The idea is simple to fetch error messages during the
engine cylces and<br>
moving them to the registered interfaces. (e.g. Shells that
outputs later the messages to the user). I would also add a more
general<br>
method for pushing each kind of messages to Observable Engine e.g.
push_messages. This is some interface a Job/PlanService could use<br>
to push methods to all RemoteInterfaces (Currently it's directly
injected to the Shell-Interfaces)<br>
</blockquote>
In the same spirit as the rest of the code, I think it would be
better to transfer exceptions directly (as objects) and then make
the ShellInterface display them.<br>
<pre class="moz-signature" cols="72">--
Sylvain Joyeux (Dr.Ing.)
Senior Researcher
Space & Security Robotics
Underwater Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
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>