Re: Alternative Transports / Master Server

On Tue, 11 Nov 2014, Janosch Machowinski wrote:

> Am 11.11.2014 um 15:47 schrieb Sylvain Joyeux:
>> 2014-11-11 12:13 GMT-02:00 Janosch Machowinski <[email protected]>:
>>> Hey,
>>> we are currently looking into adding new transport layers to orocos.
>>> We haven't choosen the concrete implementation or candidate yet,
>>> the candidates so far are :
>>>    - LTP/BT (licklider transmission protocol / Bundle protocol)
>>>    - ICE
>>>    - DDS
>>>    - zeroMq
>>>
>>> Noe we stumbled over the issue with the "Master Server"
>>> for now, there is the implicit master server, being the
>>> corba nameserver.
>> Can you explain what you mean by that ? There is no "master" server in
>> RTT the way there is one in e.g. ROS. The only server that exists is a
>> name server, which is a very narrowed down definition of "master".
>>
>> The corba client class currently registers tasks on the corba name
>> server (which made sense given that CORBA was the only name service),
>> but there's nothing in RTT that mandates it (not even in the CORBA
>> transport).
> I agree, but to be fair, without the ability to lookup up other components,
> orocos would be pretty useless.

Orocos should not be extended with this functionality, since this would be
a counter-example of "inversion of control": the projects that are
specialised in discovery and communication (Looci, and the growing set of
more recent Internet of Things middlewares) should be able to deploy
themselves into component frameworks, without the latter having to be aware
of this.

> My proposal was more aiming in the
> direction, to have a common interface for component lookup,
> independent of the transport layer that one uses.

There are tons of projects working in this direction, as mentioned above.
It would be a bad idea to add yet another of these, in the very limited
Orocos context, and with the very limited resources available.

> Apart from this there is the second question, if it makes sense, to add
> code that serves component lookup request in a transport independent way.
> This would be useful if building transports on pure protocols.
>
> It was already pointed out, there are case, were the transport middleware
> already provides the functionality of the name lookup. In this cases 
> this code would obviously not be needed.

>> It is the job of the deployment tool (either the OCL deployer or
>> orogen-generated deployments) to register the task wherever they feel
>> like. I.e. it is a tooling concern (whichever toolchain you use is
>> really what mandates the task to be registered somewhere specific),
>> definitely not a transport concern.
> Sure, but it would be great, to do something like
> ./component --useDDS
> or
> ./component --useCORBA
>
> without having to maintain two independent code base on the tooling side.

This is not my preferred solution! (Because of the inversion of control
issues.) The way to go is the following:

my_favorite_communication_project --deploy DDS --component-type my_RTT_1

(this is too simple, of course, just illustrating where the "dependencies"
should be dealt with.)

> Janosch

Herman
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev