On Tue, 11 Dec 2012, Jeffrey Hutzelman wrote:
On Tue, 2012-12-11 at 21:12 -0500, Benjamin Kaduk wrote:
Replying to myself with some comments, trawling for other input...
On Wed, 28 Nov 2012, Benjamin Kaduk wrote:
On Tue, 27 Nov 2012, Simon Wilkinson wrote:
I haven't reviewed the series completely yet, but I wonder if initial error
list for CombineTokens is far too verbose. It isn't clear to me the
situation in which many of the suggested errors would occur, and I'm wary
of over specifying here.
It's quite possible that the current list is too large. I was essentially
brainstorming when coming up with it, and some of the scenarios may be
application-specific (and thus end up in the high half of the range).
I consider the list quite flexible at the moment and welcome more input.
I'll include the current list below for the mailing list to comment.
-Ben
I don't see that an "application-specific block" is needed. Rx RPCs,
including this one, either succeed (which the library represents as a
return value of 0) or abort with a non-zero error code. With the
exception of errors emittted by the rx core, code generated by rxgen,
and (for historical reasons only) the volume package, our errors come
from com_err. rxgk should concentrate on defining error codes that are
relevant to the rxgk error or for which interoperability and reasonable
code-sharing require that a code for an application-level failure not be
application-specific. For example, it would be appropriate to define an
rxgk error code for a policy violation that application-independent code
might reasonably handle in some specific way other than just passing the
error upwards. For application-specific policy issues, applications are
free to define their own error tables, and have probably already done
so.
Further discussion with Jeff convinced me that we should not try to
standardize RPC-specific error codes, and instead use com_err tables for
everything. This makes us have RXGK-specific codes instead of
RPC-specific codes, which is probably a good thing, and also lets
application error codes come in naturally without a separate reserved
block. The com_err table is pretty easy to extend, so it doesn't
have to be perfect or comprehensive right away. Commits
3d56ed GSSNegotiate policy errors are com_err
7a9155e CombineTokens errors are com_err errors
on https://github.com/kaduk/openafs/commits/prot make these changes for
the language of the CombineTokens and GSSNegotiate RPCs, moving the list
of error codes to an AFS-3 Registry Concerns section at the end. Thanks
to Simon for pulling up YFS's error table.
Separate mail about other updates on github coming soon.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
