Distinguish between user ServiceDescription and internal representation in ServiceRegistry

[mossmaurice]

Let's continue the discussion from this thread here.

Below a summary of what happened so far.

Post from @mossmaurice:

@elBoberido @MatthiasKillat

I don't think the information how a topic can be accessed (either via popo::Subscriber or popo::ClientPort) belongs the the ServiceDescription. The best analogy I heard in the last few days is that the phone-book one. Think of the ServiceRegistry as a phone-book. Now you want to order some nice Asian food and look it up in the phone-book. The ServiceDescription would describe the food type that you can consume but not how you have to order it. A typical restaurant may offer home-delivery or eating out in the restaurant.

I like the idea of the struct:

enum class MessagingPattern {
ANY,
PUB_SUB,
REQ_RES
};

IMHO it's should just be part of the findService(service, instance, event, callable, TYPE::PUB_SUB) call. As an alternative the user could also provide REQ_RES. This would only return the search results for the specific type and the user could then either create a popo::Subscriber or popo::ClientPort to access the topic.

Answer from @elfenpiff:

@mossmaurice I think we need to define the terms first. Look at ROS2 since we are having here the same terminology:

• Topic: Publish/Subscribe communication: https://docs.ros.org/en/foxy/Tutorials/Topics/Understanding-ROS2-Topics.html
• Service: Request/Response communication: https://docs.ros.org/en/foxy/Tutorials/Services/Understanding-ROS2-Services.html

With this in mind the phone-book analogy does not fit since these are two different things.

Our service registry mixes both Topics/Services and we have to distinguish between them, either we do this by adding a MessagingPattern or we have a TopicRegistry and a ServiceRegistry. The naming is also not perfect in our case.

Just for fun, what do you think happens when we do not distinguish those things, then we will receive bug reports like:
Oh I found service XYZ but the subscriber/client cannot connect to it. To solve this impediment we then have to communicate to the user what type of service is behind XYZ?
For me the best approach would be by introducing MessagingPattern.

Answer from @mossmaurice:

I had a look at the rmw API last week. There are several findService-like functions available:

• rmw_get_topic_names_and_types() => ANY
• rmw_get_service_names_and_types_by_node() => REQ_RES
• rmw_get_publisher_names_and_types_by_node() => PUB_SUB

There are also two methods to get more info like QoS:

• rmw_get_publishers_info_by_topic()
• rmw_get_subscriptions_info_by_topic()

My latest view on how things should work in v3.0 is:

We differentiate between a user ServiceDescription and an internal representation of ServiceDescription enriched with more meta information. The information flow would be the following:

1. User creates a ServiceDescription service, which only describes the data
2. User creates a popo::Publisher(service, publisherOptions)
3. RouDi combines the ServiceDescription, QoS and the info what kind of producer was used (popo::Publisher or popo::ServerPort) into an internal representation and stores it in the ServiceRegistry
4. User does a ServiceDiscovery::findService and the internal presentation is converted back to ServiceDescription to be able to create the respective consumer object e.g. in a loop
5. To get the QoS info we could a similar method like in ROS 2 e.g. ServiceDiscovery::getOptionsForProducer(ServiceDescription& service)

What do you think of the proposal for v3.0? Would that be feasible?

cc @budrus