"David Boyes" <[email protected]> wrote: >> 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?
None. We just don't have an rx spec yet. We probably should; IIRC Kolya wrote a document some years back that would be a good starting point, if he'll let us use it. >> 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. Sorry; I don't really object to having a symbolic name, as long as we understand why it's zero. However, if you really want to avoid making assumptions based on the implementation... An Rx RPC can succeed or fail. If it succeeds, the server sends any outgoing data and output parameters and then ends the call. There is no return value. If it fails, the server aborts the call. An abort includes a 32-bit code, which is used to convey the reason for the failure. Current implementations represent this by having client stubs return 0 on success and the abort code on failure. However, this is not the only way. For example, I could see an implementation in which client stubs return no value, but throw an exception if the call is aborted. So, perhaps a constant for "success" is inappropriate after all, because on success, the protocol slot in which the error code goes doesn't exist. >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. You'll get no argument from me on this. >I was using the output of idnits, which provides nice line numbers. Hm; I'd forgotten about that. OK. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
