Re: Alternative Transports / Master Server

Am 11.11.2014 um 17:36 schrieb Sylvain Joyeux:
> My impression that you are trying to bundle two separate issues:
>   - data transport
>   - name service resolution
> For historic reasons, they are bundled in the CORBA transport, but we
> should do away with that.
Interesting question, should RTT come with a name service resolution or 
not ?

>
> What I meant by "it is a tooling issue" is that:
>   - the runtime tooling (orocos.rb in Rock) can access any number of
> name service resolution protocols, be it bound to a transport (e.g.
> CORBA) or not (avahi)
>   - the deployment-time tooling (orogen deployments in Rock) can
> register tasks on any number of name service resolution protocols.
Sure, we can add it all inside our own tooling. The question here
is if we should aim at pushing this 'upstream' to RTT, so that the
whole RTT code would benefit from it, not only our own tooling.

     Janosch

-- 
  Dipl. Inf. Janosch Machowinski
  SAR- & Sicherheitsrobotik

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-6614
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  [email protected]

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

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