On 2/5/11 4:06 PM, "Jeffrey Hutzelman" <[email protected]> wrote: > >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.
I think that's the one that Mike Meffie cleaned up and submitted as an I-D a few months ago. AFAIK, he got permission from Kolya to do so, so we may have a start there. > >>> 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. Ugh. Perhaps we're thinking of two different things -- the return code communicated in the RPC and the return code for the transaction code above it. I think we're crossing wires there. >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. In the packet, concedo. The overall transaction does have one and would benefit from explicit definition. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
