On Sat, Nov 27, 2010 at 3:26 PM, Emmanuel Lecharny <[email protected]>wrote:
> Hi guys, > > first, I'm please to inform you all that the Kerberos protocol codec has > been completed today. It was a painful job, with more than 30 000 slocs > generated. Now, it's time to include this work into the kerberos server. > > Great job guys. This was an incredible effort. > Atm I'm reviewing what we have done, and try to clean up the thing, as the > code we wrote at the end is different from what we started with, as we > improved the process a lot. There are a few points I think worth discussing. > > - The loggers. Currently, we use a per class logger. I think it's > inaccurate, as we won't be able to group all the logs for a specific > protocol in one single logger. Of course, if we want to disable the codec > logs, we can always do that by filtering on the package, but I think we > could also decide to generate all the logs into one single logger, called > "CODEC". wdyt ? > > I think the current per class way works and filtering on the package name is the way to go via the log4j properties file. > - The tests. Right now, testing that the decoder is correct is a burden. We > discussed a lot about it, and we didn't found a convenient case to test all > the possible wrong PDU we should reject. We need a tool for that, but I > doubt a tool can be written in less than a few weeks. Thoughts ? > > There's a way but it's long and exhaustive. If we can find a new contributor willing to take this on maybe as a background thread I'd be glad to guide them on it. > Otherwise, we will now have to include the codecs into the Kerberos server, > and hopefully solve the problem we had with Kerberos on top of TCP. That > could take a day. > > We will then have to check the Kerberos server itself. I'm afraid that we > might be surprised by the way it works, not in a positive way, sadly. Yes I agree - but finally we're going to have this beast tamed. > We need some client tests, so we need to setup a test env that allows us to > test the Kerberos server using some kerberos client we may write. In order > to check that those kerberos client code is OK, we need to compare it with > what Java is providing. I guess that it will take a bit of time, but I > really see the Kerberos server as a major asset. > > +1 > On the LDAP server side, we still have to work on the Administrative Point > management. I will do that on december, and I think it can be available by > mid-december. > > I'll lend a hand on this. The AP issues are really important to get right once and for all. We are close. Really close. The configuration management is doing OK, we > soon will have a decent UI to administer the server. Pierre-Arnaud is also > thinking about the best way to extend the configuration, when an implementer > want to add his own configuration for some of the extension points. He > should come with somethng working by mid-december too. > > Excellent. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
