Tracking issue for v0.X

[ssnover]

Creating this super-issue to make a list of things we want to get into the crate prior to releasing v0.3.0.

• Add default features for rosbridge_client #31
• Unadvertise Service Support #29
• Support cbor-raw encoding for messages #34 ?
• Support for rosapi #18 ?
• Improve reporting of lack of ROS_PACKAGE_PATH #23 ?

Feel free to add more, trying to get some semblance of when we're targeting what, what features we're prioritizing, etc.

[Carter12s]

Yeah I've been playing around with Github's milestone feature for this and marking issues I was intending for a release with a given milestone, but that is hard to communicate / plan around.

In general, I'm a pretty big fan of in the early stages like this releasing super frequently. Like every time we get to a stable / happy place just go ahead and release. If we had really good CI coverage I would auto-release on ever merge to master, and I'd like to get to that point.

Setting that aside what do I think the real priorities are:

Current Goal; Attract some users

None of this matters if no one starts using it

What do users need: Basic publishing, tutorials and documentation

Therefore my current priorities are:

• Better documentation / tutorials
• Better / more examples (Would love to make some more complex ones)

I have a separate longer term goal that I'd like to work towards where more of the cbor-raw work lands. I've registered a crate called topics that I'm really interested in making a generic "topics" API for rust in. I envision the ability to describe topics pretty generically with a TopicProvider, Subscribers, Publishers, etc. . The top level topics crate will define abstract traits for these things that describe the async nature, error handling, and type binding.

Then I want to implement the topics traits for a variety of "topic backends": ROS1, Rosbridge, ROS2, MQTT, tokio channels

Then we can build a lot of useful utilities on top of the abstract topics:

• CLI for echo / pub
• Monitoring tools: rates / bandwidth / buffer size
• Database / Recording tools
• Orchestration tools

I have a hunch that while channels are extremely performant, a lot of Rust use cases could be better served by a stringly identified (but still strictly typed), topic system.

Sorry this turned into a lot of rambling, but it helps me to type this all out to get my thoughts in order.

[Carter12s]

Closing this, don't think I'm going to do tracking issues like this, and instead try to pseudo standardize on releasing every merge.