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
- Does the documentation define the Users of your Package, i.e. for the expected usages of your Stack, which APIs will users engage with?
- Are all of these APIs documented?
- 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?
- If there are hardware dependencies of the Package, are these documented?
- Is it clear to an outside user what the roadmap is for the Package?
- Is it clear to an outside user what the stability is for the Package?
- Are concepts introduced by the Package well illustrated?
- Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
- Are any mathematical formulas in the Package not covered by papers properly documented?
Jeremy
- 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
- 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.
- 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.
- If there are hardware dependencies of the Package, are these documented?
- N/A
- Is it clear to an outside user what the roadmap is for the Package?
- No
- 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.
- 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.
- Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
- N/A
- Are any mathematical formulas in the Package not covered by papers properly documented?
- N/A
For each launch file in a Package
- Is it clear how to run that launch file?
- N/A
- Does the launch file start up with no errors when run correctly?
- N/A
- 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".