Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide separate arguments for publish and subscribe topic globs. #971

Open
harsh-pal-robotics opened this issue Oct 14, 2024 · 3 comments

Comments

@harsh-pal-robotics
Copy link

Currently you can pass the "--topics_globs" which is then provided for both the Publish and Subsrciber glob.

if "--topics_glob" in sys.argv:

Subscribe.topics_glob = RosbridgeWebSocket.topics_glob

Publish.topics_glob = RosbridgeWebSocket.topics_glob

And the same for the "--services_glob" which is provided for both advertise and call service globs.

The idea is that this should provide a fine-grained control whether it is possible to publish or suscribe to a certain topic.

@sea-bass
Copy link
Contributor

sea-bass commented Dec 7, 2024

This is a good idea, if you're willing to help implement it.

Also semi-related, I notice there is no actions_glob either. Guess I didn't add that when I made the action support feature 😬

@harsh-pal-robotics
Copy link
Author

For sure! I will make a PR with it!

The new args could be:

  • subscribe_topics_glob
  • publish_topics_glob (for publishing and advertising)
  • call_services_glob
  • advertise_services_glob (advertising, unadvertising)
  • client_action_glob
  • advertise_action_glob

Do you want to keep the topics_glob and services_glob arguments, which would not be breaking compatibility. And providing value to the topics_glob arg would allow for both publishing and subscribing.

@sea-bass
Copy link
Contributor

Hmm... probably the most "correct" thing to do is whatever doesn't break compatibility. But I also don't think having a redundant interface is desired.

I would say just replace it, so long as all the defaults are the same as before.

But maybe others have more opinions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants