remote_controlboard has a network server (wrapper) assigned, and RGBDSensorClient is a wrapper

[jgvictores]

Describe the bug
remote_controlboard and RGBDSensorClient are client devices, yet have network servers (wrappers) assigned:

• remote_controlboard has controlboardwrapper2 defined here.
• RGBDSensorClient has RGBDSensorClient defined here (edit: well, this actually means it is saying it is a wrapper).

I understand that this is conceptually wrong and can lead to misunderstandings and wrong code in the future due to copy+paste (issues on documenting this are on the way at time of writing, see #1707). Note that this should not affect run-time: proof is they have been there for a very long time.

To Reproduce
See code, or run yarpdev --list and see wrappers.

Expected behavior
Client devices, from my understanding, should have no wrapper (wrappers are for server sides).

Additional context
Switching the mentioned source code to empty quotes "" should suffice.

[barbalberto]

I had the same idea years ago and asked clarification. I was replied it was done on purpose, for the following reason:

The default wrapper is used only by the yarpdev executable; when you open the device via code using a PolyDriver::open(...) it is ignored.
If you run yarpdev --device remote_controlboard (without the default wrapper) you'll end up with a process that succesfully connects to the server side, but the user can't actually do anything with that client, because there is no way to access it.
By adding the default wrapper, the yarpdev will create a wrapper and attach it to the client, exposing a set of ports. The user then can write to those ports, via yarp read/write, yarp rpc and make use of the client functionalities from the terminal or another process.

Although personally think this is one of the many hidden and never used features yarp has, still it may be considered as a feature. It may also be used as a quick way to setup a local repeater.

Not all clients can work this way because some wrappers have mandatory parameters that cannot be guessed with default values.

This was just to summarize the story and explain why it is not a bug.

That said, I'm not against this change. The only difference I see is that, in case a user wants to setup a repeater, it has to change the command from:
yarpdev --device remote_controlboard <client params>
to
yarpdev --device controlboardwrapper2 --subdevice remote_controlboard <client params>

I proposed the same thing years ago and it was rejected, maybe now times are changed, but I think we need a shared strong agreement before removing a feature.

[jgvictores]

For consistency, I see 2 options:

1. Make all client devices be wrapped by their corresponding pairs, so remote_controlboard remains the same, while RGBDSensorClient should be fixed to be wrapped by RGBDSensorWrapper, and additionally promote this to RobotDescriptionClient, etc.
2. Remove this feature from all client devices where present, which AFAIK are remote_controlboard and RGBDSensorClient.

I would not like to see the issue marked as invalid/won'tfix because YARP devices are not intuitive for newcomers, and yarpdev --list saying that RGBDSensorClient is a netwrok wrapper increases confusion. I'd propose an emoji-vote with 🎉=1 and ❤️=2, but am of course open to more opinions before initiating any PR. 😄

[barbalberto]

I agree many things are not intuitive, but imho that's not enough to remove them.
In yarp terminology both clients and servers client are network wrappers, so in case we decide to go for the 2nd option, the correct change would be to mark remote_controlboard as one, like:

Device "remote_controlboard", C++ class yarp::dev::RemoteControlBoard,  is a network wrapper.

Device "RGBDSensorWrapper", C++ class yarp::dev::RGBDSensorWrapper, is a network wrapper.
Device "RGBDSensorClient", C++ class yarp::dev::RGBDSensorClient, is a network wrapper.

Device "JoypadControlServer", C++ class yarp::dev::JoypadControlServer, is a network wrapper.
Device "JoypadControlClient", C++ class yarp::dev::JoypadControlClient, is a network wrapper.

This is to distinguish between devices that deal with the hardware (therefore needs to be wrapped by something else) and devices that only deal with yarp messages over the network.

Many devices have this information missing or not correct and could be updated, but it is not clear to me if we are talking about adding/removing the feature of creating the wrapper or the yarpdev --list output

[pattacini]

What about documenting rather than removing? 😉
Launching clients, servers, wrappers with yarpdev is fairly useful.

Also, consider that there exist plenty of devices not included within YARP.

[jgvictores]

Thanks for your comments! Great to have this documented. I am rather confused on something now, I guess the following should be defined before deciding whether if the default should be set or not:

A. clients != wrappers. Evidence:

• From Device Implementations we see: Network Servers (Wrappers) vs Network Clients
• This is in line with the first response, where the client is in fact by default wrapped by the server (can be used as a repeater).

B. clients == wrappers. This is what is stated in following response, where the client is a wrapper itself.

...does anybody have a clear opinion?

[PeterBowman]

B. clients == wrappers. This is what is stated in following response, where the client is a wrapper itself.

"Clients" are to become Network Wrapper Clients (NWC) and "servers" Network Wrapper Servers (NWS) in the proposal laid out in #2441.

[barbalberto]

What about documenting rather than removing?

That's my point. It looks that we are discussing about words rather than about features (which is good anyway).

None of both citation in A states that the client is not a wrapper. They simply state the the devices are wrapped by wrappers. Clients are devices, and they may be wrapped by another network wrapper as well. It is not explixitly said that the client is a wrapper either.

Usually we refer to clients and servers as Network wrappers because their business logic is to handle network communication, they do not have any computation and do not generated or modify the data they handle.

The HW device on the contrary produce/consume data and do not have any ports and don't care where the data goes/comes from (a device can be used without wrappers). You can find more details about this idea in this presentation https://github.com/easy-peasy-robotics/easy-peasy-robotics.github.io/blob/master/editions/cpi18/yarp.pptx

So a client is a network wrapper which can, in turn, wrapped again (and again and again 😄 ) in case this is found useful.

[jgvictores]

Understood and agreed. 👍

Ok to PR as described above (mark remote_controlboard etc as wrappers)?

PS: Both a small comment and a pointer to this issue in the commit could reference the possibility of wrapping the client in a server for implementing a repeater-like functionallity.
PS2: Towards Long-Lived Robot Genes also uses the term Network wrapper for client devices.

[traversaro]

I personally always though that just servers (and not clients) were considered "network wrappers", for the following reasons:

• There are a lot of devices called SomethingSomethingWrapper, and all of them are servers. If wrapper refers to both server and clients, that naming is definitely confusing.
• Network servers obtain the pointers of the device that they wrap using the IWrapper and IMultipleWrapper](http://www.yarp.it/classyarp_1_1dev_1_1IMultipleWrapper.html). In general network clients do not implement these interfaces.

• From Device Implementations we see: Network Servers (Wrappers) vs Network Clients

Indeed in #1692 I separated the two groups (server and clients) from the original network_wrappers group because I thought wrappers was referring only to servers. If that is not the case, that documentation needs to be reviewed.