directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: Categorize KrbOption by adding group info
Date Fri, 20 Nov 2015 09:03:02 GMT
>> 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:elecharny@gmail.com] 
Sent: Friday, November 20, 2015 4:33 PM
To: kerby@directory.apache.org
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...


Mime
View raw message