directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: Categorize KrbOption by adding group info
Date Fri, 20 Nov 2015 09:52:14 GMT
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.


-----Original Message-----
From: Emmanuel Lécharny [] 
Sent: Friday, November 20, 2015 5:09 PM
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...)

View raw message