> > The return code for successful return from an Rx RPC is zero. This is > inherent in the protocol, because a successful return is represented > differently from any error return.
So what harm is done to specify that outside of an implementation? There aren't any other docs, so what's your problem here? > Having a constant for this might look > pretty, but pretending it can't th be other than zero is silly. > It may be silly but it's documenting something no one has ever bothered to write down so far outside the code of an implementation. As you bluntly commented elsewhere, this is documenting a protocol, not annotating a specific implementation. This removes an ambiguity in the protocol specification. Beyond that, whether we use a constant name or not is really a personal preference. *I* happen to think it makes it easier on the implementer to have ONE defined symbolic value that means the same thing in the entire specification but I'll take argument on that. Short version: IMHO allowing something to be assumed is bad practice for a specification. You know, the more we wiggle on this hook, the more it seems necessary to go back and actually document what the existing stuff does. That would circumvent this kind of discussion and perhaps we might be able to discuss changes more productively. > BTW, David, it would be really helpful if in your comments you referred to > sections of the document (its logical structure) rather than only to > specific line numbers in a particular representation. For example... > I was using the output of idnits, which provides nice line numbers. I find that to be a useful tool to have everyone looking at the same document... > My web browser doesn't show line numbers, so it's very hard for me to > figure out what "line 162" is here and thus to figure out what David is > commenting on. See above. Idnits will insert the line numbers in it's output for any of the formats it supports, including displaying it in the browser._______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
