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]> 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
