Proposal for removal of classes yarp::os::Node, yarp:os::Publisher, yarp::os::Subscriber

[randaz81]

These classes were mainly introduced to support direct communication with ROS1, now obsolete.

While they can be used also for communication in yarp (via topic), I think that they are not optimal and should be deprecated and removed. Here some considerations:

• The current implementation is obscure and difficult to maintain.
• Topics do no support portmonitors/protocols, which are useful and largely diffused in yarp.
• The topic paradigm is not diffused in yarp application code. Ports allow a more clean way to identify the source and the destination of the communication.
• Topics can be a trap for beginners: when using a wifi system, with limited bandwidth and latency, topics may waste resources creating unwanted/unmonitored communications broadcasted across the wifi.
• The architecture of yarp::os::Node does not support opening topics from different nodes within the same process. For example, let's consider the case of yarprobotinterface, which loads multiple plugins, each opening different topics (via yarp::os::Publisher, yarp::os::Subscriber). However, all topics will belong to the same yarp::os::Node (the first one opened), even if explicitly requested otherwise. A more precise signature of classes Publisher/Subscriber should include the node to which they refer to, i.e.

yarp::os::Node n1 ("/node1");
yarp::os::Node n2 ("/node2");
yarp::os::Publisher<Bottle> pub( n1, "/topic1");
yarp::os::Subscriber<Bottle> sub( n2, "/topic2");

Please note that this is not currently possible since it is not possible to assign to a Publisher/Subscriber a specific node (n1/n2).

• The same architecture realized by topics, can be obtained using just standard yarp ports and a repeater: by controlling where the repeater executes, it is possible to guarantee safe communication over a wifi network:

PROCESS1 --- /a --->|                                      |--- /c ---> PROCESS3
                    |----> /in --YARP_REPEATER-- /out ---> |
PROCESS2 --- /b --->|                                      |--- /d ---> PROCESS4

(please note that /in and /out can be eventually have the same name /topic and that they are here separated only for clarity of the diagram).
A novel implementation of these classes (breaking change: the new classes would have a different signature) could indeed replace the current implementation by internally implementing a yarp repeater.

[traversaro]

I could not find any use in AMI code of yarp::os::Node, yarp::os::Publisher and yarp::os::Subscriber, so it is ok for me the removal.