<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
i've committed now on a seperate branch 'jobs' in tools/roby a
partial draft for roby's remote interface. Here<br>
is the current progress:
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-15">
<a
href="https://gitorious.org/rock-toolchain/roby/blobs/jobs/lib/roby/job.rb">https://gitorious.org/rock-toolchain/roby/blobs/jobs/lib/roby/job.rb</a><br>
<br>
There are some points i've intentually keeped open (mostly the parts
where i miss some details). <br>
<br>
Here are some assumption, design issues and comments about the
specification:<br>
<br>
* There are probably better names for the new introduced classes. <br>
<br>
* 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>
<br>
* 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). Each Robot.action_command!
should use Roby::Interface for requesting <br>
an action execution. Therefore the Interface is a global thing on
the robot itself and the corresponding instance should be accessable<br>
from the Robot namespace. Each action call (execution, status
request, etc.) should flow through this component independend of the
caller location <br>
(local, remote).<br>
<br>
* 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>
<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>
<br>
* The ShellInterface is now some kind of wrapper for the
RemoteInterface, that adds several pretty-printing commands for
forming <br>
an UI. This is the single place where explicit printing commands to
STDOUT are located. <br>
<br>
* 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>
<br>
* I've ignored most of the low-level facalities (unmark(task),
find_tasks, query_methods). Of course, this could be also merged to
the Interface<br>
itself. But currently don't know if we should mix low-level- and
high-level control in this representation together.<br>
<br>
If there are some points (e.g. more capabilities in the interface),
who are not concerned by this draft, just let me know.<br>
<br>
Chris<br>
<br>
<br>
<br>
</body>
</html>