[Rock-dev] Remote Interface Draft

[Chris Mueller]

Hi,

i've committed now on a seperate branch 'jobs' in tools/roby a partial 
draft for roby's remote interface. Here
is the current progress: 
https://gitorious.org/rock-toolchain/roby/blobs/jobs/lib/roby/job.rb

There are some points i've intentually keeped open (mostly the parts 
where i miss some details).

Here are some assumption, design issues and comments about the 
specification:

* There are probably better names for the new introduced classes.

* I've introduced a new Job class, that should bind all necessary 
information (ActionModel, ActionArguments, Task instance, ID)
together. One point i'm currently not satisfied is the representation of 
the running task instance which is currently a Roby::Task
retrieved from a prepare_action command. In the current Roby::Interface 
class a PlanService is created from the Roby::Task instance,
that seems actually more appropriated. (I guess its some kind of visitor 
representation that always hold the current active
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.
However, maybe Jobs and PlanServices could be also merged together into 
a single class).

* Class Interface holds now all requested jobs in a Array and should be 
the central point for managing
the runtime behaviour of actions (Jobs). Each Robot.action_command! 
should use Roby::Interface for requesting
an action execution. Therefore the Interface is a global thing on the 
robot itself and the corresponding instance should be accessable
from the Robot namespace. Each action call (execution, status request, 
etc.) should flow through this component independend of the caller location
(local, remote).

* InterfaceProxy and RemoteInterface can be seen as the bridge between 
two machines and should implement the communication via sockets or 
another RMI
Interface (Protocol, Data Serialization, Marshalling/Dumping, etc.). 
Like Sylvian proposed, the InterfaceProxy is some kind of server, that 
dispatches
messages between RemoteInterface and the JobInterface. I'm currently 
struggling if we should create several independend proxy instances for 
each Interface
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
would move the code for syncronization concurrent accesses into the proxy.

* Roby::Interface should never have some code for remote communication 
stuff.

I've currently left the decision open for the using communication layer 
in order to specify first the central components and not messing
up the code with communication related stuff. Are there any preferences 
which layer to use? (I'll will look further into some ruby implementation
within the next days). Because of this i also ignored all DRb stuff 
within the old interface.

* The ShellInterface is now some kind of wrapper for the 
RemoteInterface, that adds several pretty-printing commands for forming
an UI. This is the single place where explicit printing commands to 
STDOUT are located.

* The old interface inject at runtime a GatherException module to the 
Roby.engine, which forms some kind of Observer-Pattern and opens
registration facalities for other instances with an Array of Strings. 
The idea is simple to fetch error messages during the engine cylces and
moving them to the registered interfaces. (e.g. Shells that outputs 
later the messages to the user). I would also add a more general
method for pushing each kind of messages to Observable Engine e.g. 
push_messages. This is some interface a Job/PlanService could use
to push methods to all RemoteInterfaces (Currently it's directly 
injected to the Shell-Interfaces)

* 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
itself. But currently don't know if we should mix low-level- and 
high-level control in this representation together.

If there are some points (e.g. more capabilities in the interface), who 
are not concerned by this draft, just let me know.

Chris



-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20130516/3b664b62/attachment-0001.htm