create publisher even without subscriber

[dirk-thomas]

The dynamic bridge polls both sides A and B and only when a publisher is present on side A and a subscriber is present on side B it creates a bridge. That bridge then consists of a subscriber on the side A and a publisher on the side B.

For some use cases like showing available topics in a user interface to choose from this doesn't work since there is no subscriber on the side B / the user interface yet.

Using the option --bridge-all-topics isn't a good alternative either since that results in potentially many more message to be transferred from the publisher on side A to the bridge (even when not being subscribed to on side B). Also if the publisher perform conditional computations based on the presence of any subscriber the bridge might increase the resource usage unnecessarily.

One option to get the best of both approaches would be to already create the publisher in the bridge for side B when there is a publisher on the side A. By not creating a subscriber in the bridge for side A yet (while there is no subscriber on the side B) no overhead is generated but the available publishers are introspectable from the side B.

[sloretz]

Is this ticket for just publishers? Does it also apply to subscribers? If a subscriber exists on side A should a subscription be created on side B for the purpose of introspecting available subscribers from side B?

[dirk-thomas]

It could also apply to subscribers. I just didn't have a use case for that one at hand 😉 If you can imagine one please describe it here so that it can be covered too.

[calvertdw]

Edit: @dljsjr I think @sloretz's proposal may fix #130. I think this issue addresses an important expectation that many users have when going to use this bridge.

[dljsjr]

@dirk-thomas it would be nice for it to apply to subscribers as well because with the current state of things, even when using --bridge-all-topics, you can't see subscribers with no publishers if you're on the "wrong" side of the bridge.

The only reason this is important to us is because we're adopting the ROS 1 bridge for users and customers who cannot use ROS 2 in any state, which means that our API endpoints are not "discoverable", it has to be rigidly documented. It's not the end of the world by any stretch but it would be really nice if we could spin up our controller and relevant subscription endpoints and have them rostopic list-able from devices where ROS 2 cannot be installed. We have to treat ROS 2 and the bridge like a "black box" for a lot of our use cases unfortunately.

[dljsjr]

@calvertdw I think if they add subscribers it might help with that issue.

[dirk-thomas]

Just to set the expectations right: this ticket is just a feature / enhancement idea at the moment. There is currently no plan (at least from me) to implement it. If anyone would like to take a shot at it that would be great.