On Tue, 12 Feb 2013, Andrew Deason wrote:
On Tue, 5 Feb 2013 11:05:56 -0500 (EST)
Benjamin Kaduk <[email protected]> wrote:
It seems that the ClientInfo structure contains all of the fields of
the TokenInfo structure (in the same order, even!). I would like to
When implementing I noticed that lifetime, bytelife, and errorcode are
unsigned in the TokenInfo, but signed in StartParams and ClientInfo. (So
the fields are not actually the same.)
I that we should make the signedness agree in all locations, with the
lifetime and bytelife unsigned, but the errorcode signed.
make ClientInfo contain a TokenInfo instead of repeating all the
fields. Both structures are in the rxgk document already.
I'm not sure if the 'errorcode' in those is conceptually the same?
TokenInfo.errorcode is an error for CombineTokens/AFSCombineTokens,
where ClientInfo.errorcode is an error for GSSNegotiate.
It could be seen as different, I suppose. It's still an error producing
the token that the structure is supposed to describe, though.
I don't know if that really matters; they both need a 32-bit error, and
they both have a 32-bit error. But it seems odd to me to either
duplicate the errorcode field, or have the GSSNegotiate error be in
ClientInfo.tokeninfo.errorcode (but maybe that's just me?).
You could treat errorcode as separate, and just have the rest of the
clients moved into another structure, TokenOptions or TokenDetails or
something. But if that doesn't seem necessary, just putting a TokenInfo
in ClientInfo seems fine.
I don't think there would be benefit in such a tokendetails structure.
However, given that the implementation is just going to have a
source-of-truth data structure for the proto-token, and copy information
from that into the ClientInfo and Token structure, I no longer see a real
need to collapse the data types.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
