YARP_manager enhancement - better application management on the network

[alecive]

Note: The reason for this proposal comes from the fact that in different contexts I wanted to have an automated way to perform app switching. I am aware that it is no small feat, but I am convinced that this should be the way to go in order for yarp to be better future-proof, and for the robot(s) using yarp to be ready to be used by non-expert users.

Preface

1. In general, we always think of the yarp network as a distributed network of modules running onto nodes, with a central server to rule them all. These modules are enclosed into applications that take care of the subproblem of connecting every single module to the resource it needs: the user opens the application, connects the ports and voilà: the lifecycle of an application is basically ended (a part from when the user closes the modules).
2. Broadly speaking, the applications we usually run via the yarpmanager can be divided into two groups:
   • Utilities : apps that are needed by other modules in order for them to function. They can be run in the background with no harm to the functioning of the modules that don't need them. E.g. robotInterface, cameras_calib.xml, Gaze and Cartesian Controllers, WholeBodyDynamics, iCubGui, skinManager: they are essential for the functioning of the robot, but they don't do much if left alone.
   • Commodities : apps that are explicitly launched by the user that wants them (e.g. the RedBall.xml). They usually need one or more utilities to be opened beforehand. Importantly, they usually need all the other commodities to be stopped or disabled in order to prevent conflicts on the platform (e.g. the RedBallDemo does need the interactiveObjectsLearning demo to be not running).

Problem

The relations between the applications we run on the yarp network are mission critical, but they are currently performed manually by the user itself. This might result in errors/malfunctionings/etc. It would be better to automatize this process by adding a new abstraction layer that considers not only modules but also applications.

Solution

To overcome this issue, the following features should be implemented:

1. A way for the network to store information related to the applications that are running on the network itself. Currently, the manager can only ping any of its nodes to discover (and act on) individual modules that are running, but there is no information related to where these modules belong or for which reason they are running (at least, as far as I know).
2. A way for the user to know which applications and how many of them are currently running on the network. I was envisioning the server to take up this role because there can be multiple yarpmanagers on the network and this should avoid conflicts.
3. The ability for the user to remotely ask for one application to be closed (via either a C++ API, rpc requests, or gui commands). Eventually, the ability for the user to close all the commodities at once.

The final scenario would be this:

• the user asks the yarpmanager to run a specific application (i.e. a specific xml file) through e.g. an rpc request : run redBallDemo.xml;
• the application xml file embeds into its dependencies field (or any other field we might find more useful) the utilities it needs and the commodities it wants to close (the latter might be also something like "close any other commodity", or "close everything but the skinManager.xml because I'm doing a demo and I would like both to be running);
• the yarpmanager (or the server) parses the dependencies and acts accordingly: it checks if all the utilities are running (by asking the server), and it eventually closes the commodities that should be turned off before running the redBall demo.