bond/Reviews/2011-01-19_Doc_Review

Please review:

• Overall explanation for bond (on the package's wiki page)

• Code API and "Example usage" for bondcpp

• Code API and "Example usage" for bondpy

Reviewer:

Instructions for doing a doc review

See DocReviewProcess for more instructions

1. Does the documentation define the Users of your Package, i.e. for the expected usages of your Stack, which APIs will users engage with?
2. Are all of these APIs documented?
3. Do relevant usages have associated tutorials? (you can ignore this if a Stack-level tutorial covers the relevant usage), and are the indexed in the right places?
4. If there are hardware dependencies of the Package, are these documented?
5. Is it clear to an outside user what the roadmap is for the Package?
6. Is it clear to an outside user what the stability is for the Package?
7. Are concepts introduced by the Package well illustrated?
8. Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
9. Are any mathematical formulas in the Package not covered by papers properly documented?

Jeremy

1. Does the documentation define the Users of your Package, i.e. for the expected usages of your Stack, which APIs will users engage with?
   • Yes -- anyone wanting to ensure two processes can monitor each others termination
2. Are all of these APIs documented?
   • No. Example usage is partially documented, but the details underlying Bond API is not explained. If I wanted to use bond with rosjs I would have to start digging into code. If this API is intended to be private, it should be stated as such. Furthermore, in both the cpp and python API, I don't understand how the generated unique_id is transmitted from the server to the client. There are a number of public members of the C++ class with no documentation whatsoever. I can make intelligent guesses about most of them though.
3. Do relevant usages have associated tutorials? (you can ignore this if a Stack-level tutorial covers the relevant usage), and are the indexed in the right places?
   • There are short example usages for roscpp and rospy but they are missing informatoin such as the necessary includes. There is no high-level tutorial, where I actually bring up 2 nodes, break the bond, and see it work.
4. If there are hardware dependencies of the Package, are these documented?
   • N/A
5. Is it clear to an outside user what the roadmap is for the Package?
   • No
6. Is it clear to an outside user what the stability is for the Package?
   • No -- It's part of a 1.0+ stack, which makes me think it should be stable, but it's also new. I have no real idea what to expect.
7. Are concepts introduced by the Package well illustrated?
   • At the highest level, yes. But there is no explanation of what is actually happening with the heartbeat.
8. Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
   • N/A
9. Are any mathematical formulas in the Package not covered by papers properly documented?
   • N/A

For each launch file in a Package

1. Is it clear how to run that launch file?
   • N/A
2. Does the launch file start up with no errors when run correctly?
   • N/A
3. Do the Nodes in that launch file correctly use ROS_ERROR/ROS_WARN/ROS_INFO logging levels?
   • N/A

Concerns / issues

Jeremy

• I am concerned by the lack of "bond API" documentation. There is no way to extend this to other languages without inferring API from existing code.

  • SG: The internal mechanisms are left purposefully undefined so I can change it if necessary. Once the internals stabilize a bit I expect to make them permanent so bond can be implemented in other languages

  • JL: Ok, this should be made clear on the main bond page, and future plans should be made clear as part of some roadmap.
• {./} The C++ and Python examples don't show the needed includes/imports.

  • SG: ok

• {./} Given the examples, I don't understand how my bond client is supposed to get the unique id.

  • SG: The unique id is negotiated outside of bond (through your own action or service). I will make that clear in the example and in a tutorial.

• {./} I don't understand if there is actually a functional difference between server and client

  • SG: There isn't. Did I use the terminology of "client" and "server" anywhere? If so, it should be changed

  • JL: I don't think so -- I thought maybe this was how the unique id transmissino might be being handled.
• {./} Using a particular ID, when I run a 3rd bond instance on the same topic everything explodes. I don't understand why, what this means, or if this behavior should be expected.

  • SG: A bond can only be formed between 2 processes. Adding 3 processes to the same bond should cause loud errors. If they weren't clear I can change them to be more clear. (Nothing should crash, though)

  • JL: They were loud but uninformative. At least in python, when I launch the third node, I get a repeating:

    • [ERROR] [WallTime: 1295655792.571048] bad callback: <bound method Bond._on_bond_status of [Bond foo, Instance 6c8aa994-97bd-4323-bac6-a76d34b5bb0c (SM.Alive)]>
      Traceback (most recent call last):
        File "/opt/ros/unstable/stacks/ros_comm/clients/rospy/src/rospy/topics.py", line 563, in _invoke_callback
          cb(msg)
        File "/opt/ros/unstable/stacks/common/bondpy/src/bondpy.py", line 197, in _on_bond_status
          rospy.logerr("Bond (%s, %s) has more than two members." % (self.topic, self.bond_id))
      AttributeError: 'Bond' object has no attribute 'bond_id'

  • SG: I've made the error messages more clear and fixed the bug that was making the Python version blow up

• bond.wait_until_broken() appears to prevent ctrl-c from bringing down the node.

  • SG: Ticketed: <<Ticket(ros-pkg 4732)>>

• An explanation of stability and future expected work would be nice.

• It would be very nice to have a complete tutorial that included making 2 nodes, bringing them up, and then breaking the bond.

  • SG: makes sense

• I don't really understand why bondcpp and bondpy needed to be separated into different packages. This seems like unnecessary package proliferation.

  • SG: Python users shouldn't have to wait for C++ packages to compile. Do you disagree? If there were Ruby, Java, Lua, Haskell, and x86 assembly implementations, should they all be in the same package?

  • JL: We had a long discussion about this. I know I won't convince you. I fundamentally agree but believe that it's the wrong solution. In the long term I expect the compile time saved for python users will roughly equal the amount of time lost by confusion when they declare a dependency on "bond" but don't remember they also need "bondpy".

Conclusion