Thanks Emmanuel! >> I just find it easier to stick to the RFC ... Agree. Just forgot to mention that in the core we do stick to the specs and define those types, like KdcOption. I would regard KrbOption(s) as the bridge or wrapper for the KrbClient API to frontend and interact with users' applications.
Note I'm not thinking in the current codes the client API (including the KrbOption) is defining ideally. Instead, it would be great to have it well reviewed and discussed before a formal release. We do have enough time for that. We've heard some comments or complains from Steve, and expect more inputs and suggestions. Thanks. Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Friday, November 20, 2015 5:09 PM To: [email protected] Subject: Re: Categorize KrbOption by adding group info Le 20/11/15 10:03, Zheng, Kai a écrit : >>> I'm not sure I see the point of having one gigantic Enum gathering all the >>> possible flags that we can set on any different kerberos element. > Ok, got your point. Yeah, KrbOption is becoming big, including all kinds of > options from frontended mechanism (PKINIT, TOKEN ...), tools (KINIT, Kadmin), > and so on. That may be basically because KrbOption(s) accompany with > KrbClient and KrbClient is full of all the client side APIs. The centralized > APIs may be easier to users to look for and use. > >>> that would make it more complex for coders to know where everything is >>> coming from and will disconnect the implementation from the RFC, making it >>> harder to understand for new comers that have the RFC in front of them. > Agree. We should definitely improve this. For now we can add meaningful > comments for each group/set of options. Further refactoring and improvement > are expected given more thinking and ideas. Will keep this in mind. Note that it's juts my opinion. I just find it easier to stick to the RFC, instead of doing it 'à la Microsoft' (ie, redefining everything...)
