Higher level api for creating pub/sub, service/client?

[levilovearch]

Hi, I'm wondering whether you like the idea of adding more newbie-friendly APIs for creating pub/sub, service/client? My initial thought is to combine the steps of creating topics and pub/sub/service/client. E.g., for creating subs,

pub fn create_subscriber<D: DeserializeOwned + 'static>(
    &mut self,
    topic_type: impl ToString,
    topic_name: impl ToString,
    qos: Option<QosPolicies>,
  ) -> CreateResult<Subscription<D>> {
    let qos = match qos {
      Some(qos) => qos,
      None => {
        QosPolicyBuilder::new()
          .durability(policy::Durability::Volatile)
          .liveliness(policy::Liveliness::Automatic {
            lease_duration: Duration::INFINITE,
          })
          .reliability(policy::Reliability::Reliable {
            max_blocking_time: Duration::from_millis(100),
          })
          .history(policy::History::KeepLast { depth: 1 })
          .build()
      }
    };
    let topic = self.create_topic(&topic_name.to_string(), topic_type.to_string(), &qos)?;
    self
    .create_subscription::<D>(&topic, None)
  }

Then we can create a subscriber by

let sub = node
    .create_subscriber::<String>(
      String::from("std_msgs::msg::dds_::String_"),
      "/topic",
      None,
    )
    .unwrap();

The rationals are:

1. It will make the APIs more like the ones rclpy/rclcpp provides.
2. It will make the example simpler as newcomers tend to not care so much about QoS configurations, while advanced users can still define their own QoS profiles.
3. For real-world applications, a node may handle multiple subs and pubs. Using higher-level APIs to create pub/subs could reduce the line of code and make the code easier to understand.

How do you think about that?

[jhelovuo]

This is a reasonable suggestion, especially point 2, as configuring QoS is cumbersome. However, as you may have noticed already, we recently added some default constant QoS values, which should simplify Topic setup.

Reducing the line count is also a good idea, but we are not yet ready to take this step. Our plan is to first improve the typing of Topic and Publisher / Subscription construction so that various names are not given as plain &str , but a custom type instead, which should help to make code more explicit and improve correctness.