>> once Kerby is matured enough then we can add a dependency on it in ApacheDS >> and integrate. Is there any good sign in your view for the maturity? It looks reasonable, but should we wait and do it then? I guess some pioneering work in ApacheDS side would be tried first.
>> The current code base tries to support way too many configuration formats >> and I would like to see it support only one format, well and complete. Well, kerby-config may attempt to support various formats, but in the main/Kerberos part, only MIT format is used right now. I agree we may support a ‘standard’ format if krb5.conf isn’t any good standard. In your view, what’s left to be complete? Writing or generating of configuration file in a format? Or whatever? >> And then we can add a GUI config editor in Studio easily. Did you mean we need to generate a config file after some editing using the GUI tool? Kerby-config module allows to load configuration items from a Java Map/Properties, which may work here. I mean, the edited values can be stored in any form and then all the values can be loaded in a map for config to use. Regards, Kai From: Kiran Ayyagari [mailto:[email protected]] Sent: Friday, July 31, 2015 12:15 PM To: Apache Directory Developers List Subject: Re: Leveraging Kerby Kerberos library in ApacheDS On Fri, Jul 31, 2015 at 6:49 AM, Zheng, Kai <[email protected]<mailto:[email protected]>> wrote: Hi all, I’m thinking about what would be next steps after Kerby 1.0.0 out. We originally discussed when Kerby is ready, we’ll replace existing Kerberos related codes to simplify the code base in ApacheDS. This will include both the server and the studio. I thought this is important for the parent project, IMHO, the code base with so many external dependencies is rather complicated to move on (checking styles etc.), and also not easy to use. For example, so many modules, just hard to figure out the combination when only need a part of it in my app. once Kerby is matured enough then we can add a dependency on it in ApacheDS and integrate. The concern that I have at the moment is Kerby's configuration, The current code base tries to support way too many configuration formats and I would like to see it support only one format, well and complete. I am fine if we plan to support MIT krb5.conf format in _addition_ to our standard format but having more than these two formats slows us down. My personal preference would be to support JSON or YAML besides the krb5.conf. And then we can add a GUI config editor in Studio easily. Any thoughts? Regards, Kai -- Kiran Ayyagari http://keydap.com
