Kean Johnston wrote:

...

Authorization is the job of the ACL engine. Putting ad-hoc rules into user entries is, in a word, stupid. It's also unscaleable and will become an administration nightmare.

Well OK then. Using a configuration mechanism like ACL's that cannot be distributed to multiple users (like editing a directory can) is, in a word, stupid. It is also unscaleable and will become an administration nightmare. And authorisation is not (or SHOULD not be) the job of ACL's its the job of authorisation modules, which nssov is.

Being forced to give admins who simply want to be able to change access to a random host in a centralised server root access to what may be a critical server with other sensitive data on it is simply wrong.

You seem to be laboring under the false premise that root privileges are required to administer authorization in slapd. Since that is false, the rest of your statements are moot.

...

The user host attribute functionality is deprecated. I have no desire to make it even vaguely appear to be useful.

Then don't sell it as one. You claim pam_ldap compatibility but that is false. The user docs also aren't nearly as strongly worded, saying that the hostserver and ACL's is preferable, not that userhost is deprecated.

A flexible solution gives administrators the opportunity to use the tool in ways you haven't conceived of because it works for them and their environment. A ridgid and dictatorial tool forces people to do things one way and one way only. I have worked for one of the larger software companies and can tell you that the ACL mechanism would scale orders of magnitude worse, and they did, in fact have authorisation info stored in user and host attributes because that was the only way to delegate responsibility to multiple groups.

That may have been true of that other software package. That is not true here.

PS, you may wanna consider dropping the Ulrich Drepper attitude. When a contributor, especially a first time one, who has gone to considerable lengths to follow all the guidelines and do things just your way has, as his first experience someone calling things "stupid" ... well, that will thin the development herd considerably.

No, I should rather step it up a notch. I don't want contributions from J. Random Developer. I want contributions from people who participate in the community. That means reading up on how things are done, following the established practices, and demonstrating a familiarity with the way things are done and establishing a familiarity with the other community members. That means showing that you'll take the time to stick around and continue to maintain/support your code if we pull it in. If a developer won't put that time in up front, then I don't care how good their code is; I don't want to be saddled with it when they inevitably disappear.

The established practice for contributing new code is to discuss it on the openldap-devel mailing list first, before spending any time on actual coding. After the developer community gets a chance to think about it and weigh in on whether it's a good idea or not, then you start (or don't start) writing the code and submitting to the ITS.