[Rock-dev] Fwd: Remote ActionInterface for Visualization

[Chris Mueller]

Am 02.05.2013 09:58, schrieb Sylvain Joyeux:
>
>> As you already know i'm currently evaluating roby's remote interface 
>> in order to provide all necessary data for Allan
>> to implement the Robot GUI.  I've found now some time to look more 
>> deeply into the roby's sources and i would like to share
>> you some informations (I have also some issues to discuss)
>>
>> We have currently the following use cases for the GUI:
>> 1) Get and visualize a complete list about all available behaviours
>> 2) Get and visualize a complete list of running behaviours
>> 3) Support an Interaction-Interface to start and stop behaviours
>>
>> Issue (1):
>> We need a mechanism to filter out the behaviour actions from the 
>> rest, because currently all behaviours are pure Roby::Actions.
> In my opinion, it should stay that way. Actions *are* the available 
> behaviours. Can you give me a different use-case ?
Not really. This issue was only corresponding to our specific 
requirements. (Depends on how much information we want to visualize in 
our GUI,
but that should not affect the internal remote system).
> My preference is for a cleanup. It should not require so much work
>   - create a CommandInterface class that is instanciated in the 
> running Roby controller and provides an API to access the high-level 
> information. It would never generate any strings, only return or call 
> callbacks with objects
>   - create a CommandInterfaceServer / CommandInterfaceClient using 
> pure sockets and Roby/Ruby- marshalling to send data through (or maybe 
> even http or xmlrpc if you are interested to get in there ?). The 
> CommandInterfaceServer would be a proxy over a CommandInterface 
> object. As much as I like DRb for quick stuff, it has major issues. 
> One of them being that it requires the name resolution to "just work", 
> which is rarely the case with robots.
>
> What we need to discuss is the required API. I would suggest that you 
> propose one API (class layout with empty methods and yard 
> documentation) and we discuss from there
Okay. I'm responding later if i have a concret draft for the API.
>> e.g.:
>>  - i could start to branch roby and try to refactor it on myself (or 
>> we specify an interface that can be implemented by sylvain later, if 
>> it takes too many changes
>> in sources)
> +1