This wasn't a formal API review, just an e-mail exchange on ros-developers. My concluding thoughts, plus a link to the discussion thread are below.

https://code.ros.org/lurker/thread/20101025.210235.972a7414.en.html

Motivation

There is a growing base of custom code for converting YAML into messages, possibly due to the rostopic echo format. Now that rostopic is even more YAML compliant, this may accelerate.

There is a growing base of custom YAML code is using routines that are targeted at internal tools (e.g. roslib.message.fill_message_args). Also, with respect to data longevity, one must find the custom script that goes with the data to interpret it.

So, much like rostopic echo/pub replaced numerous talker/listener scripts, this discussion is meant to discover to what extent and where to invest resources in a YAML toolchain for messages that can replace these code and data files with shared practices.

Questions

• Should we promote Bagys as a proper ROS concept? i.e. raise them to the equivalent level as Bags?
• Is this a useful toolchain or just a hack?
• Should Bagys have their own tools or rely on standard Unix tools?

Conclusion

The answer from this list is that this shouldn't be a top-level concept. It also creates confusion for roscpp users. I would still like to come up with a name other than "YAML" as a code API that simply refers to these files as "YAML" is difficult. Unless someone suggests an alternative, rosh will continue to call these bagys.

Also:

• 1) Decouple the dictionary-based representation from the idea of bagys. Bagys implies a file-based source, whereas the dictionary-based representation of a message is the driver. 2) I may create command options in rostopic and rosservice for using YAML so that they can be used in launch files (e.g. to store service call values, latched data, action goals, etc...). 3) Ideas like "Map Bagy" and other sorts of metadata-driven bagys need to go back to the drawing board a bit. There aren't enough use cases to generalize from, and it's not clear this is possible yet. For rosh I will specify map bagys as experimental for ROS 1.4.

Beyond that, the feedback that this is still a hack, and I should wait to see how things evolve before pushing any further.