Mailing-List: contact kerby-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kerby@directory.apache.org
From: "Zheng, Kai" <kai.zheng@intel.com>
To: "kerby@directory.apache.org" <kerby@directory.apache.org>
Subject: RE: How about kerby-common to put non-kerberos facility modules into
Thread-Topic: How about kerby-common to put non-kerberos facility modules
 into
Thread-Index: AdFMTLNbx/zw3SV1QqO3FMtGs6SQ5AD9jN6A
Date: Sat, 16 Jan 2016 09:47:40 +0000
Message-ID: 
 <8D5F7E3237B3ED47B84CF187BB17B66614871430@SHSMSX103.ccr.corp.intel.com>
References: 
 <8D5F7E3237B3ED47B84CF187BB17B6661485BAA7@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: 
 <8D5F7E3237B3ED47B84CF187BB17B6661485BAA7@SHSMSX103.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Just got this done.

-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]=20
Sent: Monday, January 11, 2016 4:48 PM
To: kerby@directory.apache.org
Subject: How about kerby-common to put non-kerberos facility modules into

Hi folks,

I recently added a new module kerby-xdr under the root in kadmin-remote bra=
nch, which made me believe that we will need a better container to contain =
such non-kerberos specific things.
Now we have under the root module:
benchmark/
build-tools/
docs/
kerby-asn1/
kerby-backend/
kerby-config/
kerby-dist/
kerby-kdc/
kerby-kdc-test/
kerby-kerb/
kerby-pkix/
kerby-provider/
kerby-tool/
kerby-util/
kerby-xdr/

they can be divided into three groups:
support:
benchmark/
build-tools/
docs/

non-kerberos facilities:
kerby-asn1/
kerby-config/
kerby-pkix/
kerby-util/
kerby-xdr/

kerberos:
kerby-backend/
kerby-dist/
kerby-kdc/
kerby-kdc-test/
kerby-kerb/
kerby-provider/
kerby-tool/

I thought support and Kerberos relevant would stay under the root, for non-=
kerberos related facility modules better to have a container module to put =
them in.
How about kerby-common? Initially we used kerby-lib since haox but gave it =
up later during reorganization. I thought we need to bring the similar stru=
cture back, because as it's going, we'll come up more and more facility lib=
raries. It's just introducing a new container, and won't affect the module =
affects.

How would you think of this? Thanks.

Regards,
Kai