How about kerby-common to put non-kerberos facility modules into

["Zheng, Kai" <ka...@intel.com>]

Hi folks,

I recently added a new module kerby-xdr under the root in kadmin-remote branch, 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 structure back,
because as it's going, we'll come up more and more facility libraries. It's just introducing a new container, and won't affect the module affects.

How would you think of this? Thanks.

Regards,
Kai

RE: How about kerby-common to put non-kerberos facility modules into

["Zheng, Kai" <ka...@intel.com>]

Just got this done.

-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com] 
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 branch, 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 structure back, because as it's going, we'll come up more and more facility libraries. It's just introducing a new container, and won't affect the module affects.

How would you think of this? Thanks.

Regards,
Kai