Unnecessary duplication?

We are moving from http://drupal.org/project/ldap_api to http://drupal.org/project/ldap. After looking at conventions, we thought ldap better reflected current conventions of apis like calendar and token. Its likely a package with some ldap modules in it and a core ldap_api module, so ldap api didn't seem quite right.

I appreciate you keeping an eye on duplication efforts; its critical in open source. Its best that I clarify my thinking on a new module.

And I can only speak for myself here.

The maintainers of LDAP_integration have done quite a good job over the years. And there are a ton of support requests and bug requests in their queues, many of which are likely people that are just having trouble figuring out ldap. So I applaud their work. The structure of the module's code makes their work even more difficult.

However, I don't think the ldap integration maintainer(s) and I are a good fit as co-maintainers. I have worked in the issue queue on ldap_integration and offered several patches and generally am not happy with the way its gone. I ended up writing an ldap_help module just to try to help users out with it. I rewrote ldap groups in an object oriented manner and cleaned up a ton of the code and the patch was rejected because it was object oriented. I try to offer as much support as I can to local ldap_integration users but feel the solution is a rewrite not a continual tweaking of ldap_integration. Besides the architecture of the module, its been a bear to get the authentication and authorization separated and I've lost track of if that's even been accomplished there. It is important to be able to leverage ldap for authorization without using it for authentication and vice versa.

An ldap api needs a different approach than what ldap integration has. It needs multiple developers, solid unittests, a network of testers with a variety of ldap implementations to run the unit tests and active collaboration with the other ldap modules to make sure the api supports their needs. It needs reliable releases not years of dev and beta releases. LDAP integration has a sort of trial - user feedback - patch cycle with basic functionalities that are testable being tested by people who download the module. Unit testing and regression testing are preferable and then the community feedback cycle can focus on feature sets, use cases, and usability rather than finding bugs.

I also prefer an object oriented model for representing things like ldap server or ldap entries; it seems like a natural fit. With PDO in 7, there is great potential for levearging object oriented architectures with trick like binding db configuration data directly to ldap server configuration objects. There are other smaller differences between my coding style and ldap integration. I like to offer more hooks, more caching, less global variables, less db queries, less code in .module files, and better leveraging of core functions.

I laid out what I was looking for in an ldap_api (see http://drupal.org/project/ldap_api design principles) and have been accepting co-maintainers that agree with those design principles. If you agree on basic design principles, you can get more done.

Sometimes in the open source community its best just to agree to disagree on architectures and have competing projects than try to work with other developers that have different architectural preferences. The latter can lead to a muted, compromised result.

That's possibly the most complete answer I've ever seen to such an inquiry. :-) Please link to this issue from the project page for future reference.

John, I added a section up on the main page for this, Could you throw a paraphrased version there?

This is an important effort given the types of larger organizations entering the Drupalsphere where easier integration with existing systems is sometimes the make or break decision around using Drupal or not. Adapting to these changing needs with some velocity will help Drupal compete with other solutions in the long term and it seems your design goals will make it easier for all those who need to implement LDAP integration as part of their project.

We're seeing LDAP related requests show up with more frequency amongst Acquia's subscribers and frankly we don't have very much expertise in this area on our Support team. I'm looking to see how we can have a couple people participate at some level to help support this initiative and to learn as we go. We can at least get set up to help test.

I understand Chris Porter from our PS group has been accepted as a co-maintainer on this project. Great to hear. We'll work with Chris to get direction on where we can help with testing once things get to that stage. Use case and some types of environment testing are probably where my team can add the most value.

Just a question on the text in the Project page.

Does "Drupal <-> LDAP" mean that this module will be created to work both ways?
1. Drupal can authenticate against other LDAP servers
2. Drupal can be used as an LDAP server and have its user database to use as LDAP login on other sites?

I'm sure that #1 is possible with ldap_integration.module but just to clarify, is #2 part of this ldap.module's direction?

Sorry, the whole thought behind the Drupal <-> LDAP symbol was to show two way syncing of data. Drupal will act more like a write-through cache to LDAP (it stores a copy of user/form data itself while writing it back to LDAP). In the future, I would like to see the LDAP API used alongside the database abstraction layer for Views.

+1
Would really good if there is soon a stable (starting simple) LDAP for Drupal 7. Drupal 7 will be a serious candidate for corporate intranet. Looking forward to an alpha release soon :)