Mailing-List: contact kerby-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kerby@directory.apache.org
Subject: Re: Categorize KrbOption by adding group info
To: kerby@directory.apache.org
References: 
 <8D5F7E3237B3ED47B84CF187BB17B66611CC8733@SHSMSX152.ccr.corp.intel.com>
 <564EDACE.2080204@gmail.com>
 <8D5F7E3237B3ED47B84CF187BB17B66611CC8E2B@SHSMSX152.ccr.corp.intel.com>
From: =?UTF-8?Q?Emmanuel_L=c3=a9charny?= <elecharny@gmail.com>
Message-ID: <564EE344.3070801@gmail.com>
Date: Fri, 20 Nov 2015 10:09:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
 <8D5F7E3237B3ED47B84CF187BB17B66611CC8E2B@SHSMSX152.ccr.corp.intel.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

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