Coincidently, the ROS-users mailinglist has a thread going on about some of
the issues that belong in the current context of "RTT 2.0":
<http://sourceforge.net/mailarchive/forum.php?thread_name=103101d70904230854i72d85010w7d70d94f99299532%40mail.gmail.com&forum_name=ros-users>
It's not a coincidence that it is also a long thread :-) The reasons are
similar to those why are recent RTT 2.0 threads are so long: different
users bring different use cases and different design criteria into the
discussion; as well as different _implicit_ policies...

Some of the topics that I want to single out from that ROS discussion:

- the problem about setting and getting properties of components. What
access does one component have to the configuration settings of other
componetns.
- distributed locking: "If you look at an open standard for parallel
computation like Open MPI (http://www.open-mpi.org), you'll see that one
of the features it has is the concept of network mutexes/semaphores. This
allows programs to lock or wait on particular conditions in the network set
by other processes. Because ROS is looking more similar to a distributed
architecture for parallel computation, why not also support this
functionality in the parameter server? This would completely change the way
we think about network parameters and can enable applications where
"parameters that other nodes should read" starts becoming relevant.

You will not be surprised to hear that I think RTT should _not_ go this
way...

- the answer of a major developer (Ken Conley) make me think that ROS is
adding "Coordination" policies into libraries, leading to too much
coupling... (I might be wrong here!)
The origin of these couplings are, in my opinion, that ROS is considered
too much as merely a set of "object oriented" libraries, without the
concept of "component based development" explicitly present in the
designs.

- they could have copied the whole "property bag" functionality from RTT...

- Some signs of data inconsistency problems due to ambiguous Coordination:
"if parameters are cached and a node skips communicating with the
master because cache is hit, how do you determine if the parameter on
the master (where the parameter server resides) wasn't changed? do you
get some type of notification? What would it take to expose those
notifications and use them for specific parameter callback scenarios?
As far as I know, the *only* thing i've ever see ros parameters being
used for is initialization of node configurations. They aren't used
dynamically at all (ie nodes changing other nodes' parameters during
runtime) because there isn't a solid API. Imagine that there is an
array of parameters (intrinsic camera matrix for example) that need to
be set at the same time in order to avoid nodes reading a mixed set of
old and new parameters. Currently the ros parameter server is not
designed to deal with these types of situations."

- and some signs of the same kind of "architectural best practice" that we
have defended in Orocos too:
"It will be crazy to have the programmers have to check on parameter
states, check parameter time stamps hope to avoid race conditions with
other nodes etc.
In an operating robot, these things probably belong under the executive.
The executive knows what the robot is trying to do and can orchestrate the
parameters accordingly."

(ROS "executive" -> RTT "supervisor", "Coordination" component...)

- consistent data flows (un)supported by the framework:
"there's still the need for an atomic update to multiple parameters.
I'm not sure if there's support for that on the parameter server."

- the issues of method calls vs messages:
"Using setParam() seems simpler, more transparent and decoupled than
specifying service calls for every parameter or group of parameters we
might want to change.

- the issues about coordination dependencies:
There could be an issue with multiple nodes trying to control the camera at
the same time, but I think the executive already handles this sort of
node-level resource allocation. It's perfectly fine for nodes to adjust
parameters that are read by a single other node, as long as the executive
is informed of all the dependencies."

Herman