[Rock-dev] Remote Interface Draft

[Sylvain Joyeux]

On 05/16/2013 04:18 PM, Chris Mueller wrote:
> * 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).
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.
> * Class Interface holds now all requested jobs in a Array and should
> be the central point for managing
> the runtime behaviour of actions (Jobs). 
The authoritative list should be the plan, not the interface.
> Each Robot.action_command! should use Roby::Interface for requesting
> an action execution.
If all the tracking is done by the Roby plan, no need to do that.
> * 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.
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 { }
>
> * 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.
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.
> * 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)
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.

-- 
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: robotik 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
----------------------------------------------------------------------- 

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