Thanks for the feedback! >> If we are already nearly ready to go with releasing Kerby anyway, I'm not >> sure I see the benefit of releasing the ASN.1 library separately. I share the same thoughts with Colm on this. If we don’t see any major big concern to cut the 1.0.0-rc1 release, we can go directly for it. Having the ASN.1 part out would complicate the relationship between it and the main part in project management. We could consider this option in future.
Regards, Kai From: Colm O hEigeartaigh [mailto:[email protected]] Sent: Friday, July 31, 2015 10:40 PM To: Apache Directory Developers List Subject: Re: Leveraging Kerby Kerberos library in ApacheDS Hi Emmanuel, If we are releasing the ASN.1 part of Kerby independently, then doesn't this imply that it should be considered as a separate (sub) project? If we are already nearly ready to go with releasing Kerby anyway, I'm not sure I see the benefit of releasing the ASN.1 library separately. Just my 2c, I'll defer to the majority opinion on this. Colm. On Fri, Jul 31, 2015 at 9:27 AM, Emmanuel Lécharny <[email protected]<mailto:[email protected]>> wrote: Le 31/07/15 09:36, Zheng, Kai a écrit : > >> we can start by releasing teh ASN.1 part of Kerby, and use it in ApacheDS > I thought it may depend. If we still have a long way to go for the cut of the > first release, then better to release the ASN.1 part first for the use; but > if we could get it done not too late, then ... The rational here is that we need this ASN.1 lib for ApacheDS, regardless of Kerby. Let me explain what I have in mind here : - from day one, the idea was for Kerby to be independant from ApacheDS, as much as possible, but still making ut possible to bundle the two guys into a single package. - you have proven that the ASN.1 codec we are using in ApacheDS is slower and more complex than the one in Kerby - regardless of Kerby/apacheDS relation, we want to use the best possible codec. That being said, I think that releasing the ASN.1 lib first could be a sweat plan : - first, it's almost ready : it works, the code is quite clean, and it's small - second, that would be an excellent exercise for the kerby project : cutting a small release first to learn how it's done would benefit everyone in Kerby - third, this will be a shared library anyway. I can forsee that the ASN.1 lib would be of use for other projects as an independent sub-project (like MINA or the LDAP API) Now, this might be just me. wdyt ? > >>> AFAICT, Kerby is having its own code to manage communication. We depend on >>> MINA. If we have to get rid of MINA, that's fine. > Ah good point. It's a major issue we need to address. Since ApacheDS uses > MINA I thought there is no good not to use it for the Kerberos functionality. > We may enhance kerby KDC server to support plugin network mechanism, which > needs some work, but won't be very hard. MINA was used in ApacheDS for a good reason : back in 2003, when ApacheDS was started, Alex didn't want to spend some time on the network layer (I can understand) and decided to check on the internet if there was already something wrapping NIO available. He found Netty 1, and asked Trustin to join the project. It became MINA. At some point (2007?) MINA become a top level project, and we continued using it, but it became more and more complex. Many features added in MINA were not necessary for ApacheDS, and I must admit I spent a HUGE portion of time fixing bugs in MINA to get it working fine (well, more or less). In any case, I do think MINA 2 is overly complex, and the way we use it in ApacheDS is clearly sub-optimal. Now, the problem is that replcaing it with something else will be difficult. When it comes to Kerberos, we have to support TCP *and* UDP, plus the switch from TCP to UDP. We also have to deal with concurrent requests in ApacheDS, where one request can potentially be interrupted by an Abandon request (that means we can't block a session at all). That makes it quite complex to handle, if we were to rewite the whole system. Bottom line, I think that MINA 3 should address those issues, but there is a 3/6 months effort to put there, and we have many other more urgent tasks to complete before. So, here, we should have a discussion. > > I thought we could first focus on ApacheDS side (then Studio), attempting to > use Kerby to replace the old Kerberos codes. This would be a post-Kerby 1.0 task, agreed. > It's nicer to do it piece by piece and get the changes in incrementally, but > I guess some time it's hard to break down into tasks. IMHO, it's better to do it piece by piece, because in order to do that, you have to decouple the code. If the code is highly coupled, we will face some bigger issues later on. > Maybe we can have a branch for the attempt if anyone would help with? Without > some trying, something won't expose. It may be not possible to come to the > good time point when Kerby is well prepared for ApacheDS, on the other hand, > trying to do the integration work will expose some issues/enhance > opportunities/adapting things in Kerby side. A branch might really be an option. Nothing replace real world experimentation :-) If you have some time, feel free to play around ! I'm just trying to proviude some feedbacks and perception of teh potential roadblocks, certainly not saying we should not try ! Sometime it's better to unleash people, and let them experiment. If they don't succeed, at least they will understand better why ! -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
