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

Consider splitting ROS1 native functionality into its own crate #176

Open
Carter12s opened this issue Jul 8, 2024 · 0 comments
Open

Consider splitting ROS1 native functionality into its own crate #176

Carter12s opened this issue Jul 8, 2024 · 0 comments
Labels
enhancement New feature or request ros1 For issues affecting the native ROS1 implementation

Comments

@Carter12s
Copy link
Collaborator

When we started I thought (hoped) that ROS1 native implementation and rosbridge implementation would share a lot more code.

As its stands they are like 99% fully independent and really only share the same codegen tools.

I think we should ultimately split ros1_native out into a crate roslibrust_ros1 and also potentially split the rosbridge functionality out into roslibrust_rosbridge the core roslibrust crate can ultimately contain a common trait based API for both implementations and re-expose the child crates with pub use statements.

As it stands if someone wants to use ros1_native functionality only, they have to pay the cost of compiling the rosbridge functionality...

@Carter12s Carter12s added enhancement New feature or request ros1 For issues affecting the native ROS1 implementation labels Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request ros1 For issues affecting the native ROS1 implementation
Projects
None yet
Development

No branches or pull requests

1 participant