> But the "transaction" above it doesn't exist in a standard. While > conceptually it exists, the only place it's really documented as such > is > in the existing implementation(s). So, as I read it, giving the RPCs a > successful return code is already tying us to the implementation, since > it just comes from the convention of the C librx implementation. At > least, that's how I read "if you really want to avoid making > assumptions > based on the implementation..."
Gotta start somewhere. Implied operations are not good practice -- if you know something is going to happen, document it in a clear, unambiguous and understandable fashion. Then we don't have this sort of discussion for the next time. Really, how tough is it to #define RX_SUCCESS 0 and then use the constant in the text instead of hardcoding a fixed value in the spec? Doesn't change the logic, and if someday there IS a reason to change it, you don't have to go back and update a whole bunch of specifications. It improves the readability and understandability of the document for future readers. > Personally, I'm fine with just saying "0" for now, just since it's > consistent with the other RPCs specified. Using a constant in a > document > just for defining a new RPC seems like an odd place to introduce it. Again, where else should you start, given that there isn't anywhere else to do it? Previous bad habits aren't a good thing to propagate, and this is the opportunity to start doing it in a forward-looking way. Congratulations, you're the test case. 8-) _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
