Thanks for enumerating those. I agree whole-heartedly with all of them. (Especially the last! I implement my tools like that and it’s been very useful.)
I strongly support having a non-ROS based interface. You’ve listed the advantages already. However perhaps it could be useful to have a ROS-based interface in case someone wants to use the functionality from a node? Perhaps this should be a lower-priority feature unless we find an actual use case for it.
Yes, there are several ways that this could go. I think that if we use an environment variable that we can build an automatic mechanism without too much trouble. For example, the rostopic tool/library could look for an environment variable defining the graph information daemon’s address, and if it isn’t defined attempt to contact one on the local machine. If that doesn’t work then it could request the daemon be launched on the local machine.
Absolutely agree. This is another benefit of hiding it behind a well-known service description, I think: It becomes easier to abstract away the implementation. Then we can look into using existing technologies such as those @Barrett_Strausser mentioned and see if they do what we need already.
I’m in favour of a REST service as the initial goal. I’ve also been told by someone locally who does a lot of tool implementations, using the browser as an interface, that he wants “everything” to be available over REST. I’m assuming he’s talking about introspection facilities, not absolutely everything.
However, I think the information should be available on other protocols from the same daemon if someone wants it that way. If we specify the data structure and the protocol used to access it separately then it should be relatively easy to add additional access methods.
Being able to configure which domains the daemon aggregates data for, and run different daemons for different domains, sounds like a sensible use case. Especially with the potential for using domains for security zone partitioning.