Re: Alternative Transports / Master Server

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.

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.

And for what it's worth, not using native name service resolutions
looks ill-conceived as it separates the RTT/Rock tooling from the
transport's tooling (you want to use DDS-enabled tools to inspect your
system ? You can't ! Names are registered on the Rock name service !)

In summary, I really don't see what is achieved by adding
yet-another-name-service in the system. It sounds like it simplifies
the runtime tooling, but does so at the cost of a lot of loss of
interoperability. However, since the runtime tooling already supports
resolving from multiple name services, and will have to if you want to
interoperate with other frameworks (e.g. ROS), the simplification is
really moot from my point of view.

IMO, the same way that any number of transports can be used in
parallel in the same running system, we should aim at being able to
use any number of name services in parallel (we already do that with
ROS and CORBA). Because name services, as transports, have different
runtime, performance and robustness guarantees. avahi takes up to
seconds to propagate new information. CORBA is instant but needs a
centralized server (great for local installs). I personally plan to
not use any for e.g. syskit: since syskit already starts all
components, it can use its own infrastructure to load the CORBA IORs.

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