Hi all, I just want to report on some interesting conversations on IRC and IM that I've had recently and the clear conclusions it has led a few of us to. First let me state the problem:
The server is tightly coupled to JNDI from the protocol provider down into the core. The intent to use JNDI originally came from the idea that people are used to JNDI and so if used as the wrapper API around the server it would ease the learning cure. Furthermore using JNDI interfaces to achieve this made sense since it would reduce the transformation overhead when embedding the server making it more efficient. Furthermore when used in conjunction with stored procedures JNDI would allow procedures to be written outside of the server and (in theory) tested outside of the server just by switching the JNDI provider from the SUN LDAP provider to the embedded LDAP provider in ApacheDS. Although the idea to use JNDI to reduce the learning curve is a good one the implementation which coupled the server internals with JNDI details is causing us serious problems. The JNDI provider would have been better implemented as a wrapper around internal API's that are more aligned with server side LDAP centric data structures. Because they are not one must be aware of JNDI and the complexities of interchanging from JNDI environment variables to and from the core data structures. The entropy is high and results in a lot of one offs in the code. I have always wanted to fix this problem but never had the bandwidth to do it. It just stuck and rooted itself as we built upon this foundation. Years ago Trustin Lee had expressed the desire to strip out the JNDI coupling as well but he too ran into the same hurdles. Enrique Rodriguez had other issues revolving around the side effects of JNDI in the core while dealing with an OSGi based version of the server. A few weeks ago David Jencks expressed his dismay over having to use JNDI to configure the server and wondered why we do not wire the components of the server directly. Recently Emmanuel Lecharny and I paired up to review the authentication subsystem for some clearly needed changes. However at some point we realized that JNDI is excessively complicating the simple picture that should be there. So we stopped after some point. Later in the day today I had a conversation with Chris Custine about these problems on IM. We reviewed the problems and thought about what it would take to strip out JNDI while removing these configuration beans getting in the way of directly wiring up the server. We reached similar conclusions. We're going to have to bite the bullet on this one at some point or another if we intend to build on the architecture without loosing time and energy dealing with the trouble that this JNDI coupling brings with it. Chris said he's on board with just doing it. So am I. David and Emmanuel wants to as well but we need some confirmation from them. With the recent discussions to delay the 2.0release I think this is a great time to just take care of this problem once and for all. Also now we have many more hands and minds to do this right relatively quickly. While doing this we're going to break many things. It's not going to be pretty. So I recommend switching to a temporarily branch so we're not caught with broken builds on the trunk. Then we can immediately merge the changes back into the trunk and delete this branch. No need to worry about the trunk running away from us since most of us on this branch will not be working on it and well the branch should last at most 2-4 weeks. I'd like to get it done sooner but I am afraid the fallout from the changes will be very significant. I am going to just branch now and start working on this. If yall want to join me then let's go to town. I'll post the SVN URLs to this tread. And of course we can have the team review where we go before merging back but then again most of the ApacheDS active community will be in this branch anyway. Thoughts? Alex
