>> 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.

Thanks.

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:[email protected]] 
Sent: Friday, November 20, 2015 4:33 PM
To: [email protected]
Subject: Re: Categorize KrbOption by adding group info

Le 20/11/15 01:44, Zheng, Kai a écrit :
> Hi Steve,
>
> Ref. https://issues.apache.org/jira/browse/DIRKRB-458 you're going to add 
> about 15 KDC flags into KrbOption. As we discussed it sounds reasonable. Now 
> here I'm considering it may be good to categorize them or easily identify 
> them as 'kdc flags', thus it would be much elegant to pick them up and 
> transform them to KdcRequest. How about adding a 'group' field to the 
> KrbOption enum? It could be done while you make the changes or we can do it 
> separately. Thanks.

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.
The specification has carefully categorized the various options in different 
structures.

IMHO, 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.


KISS...


Reply via email to