The ones that are really problematic are the lack of:
- RFC 2891 (server side sorting)
Why is this problematic? Server side sorting is a horrible waste of server CPU that's better served by the client doing sorting how it wants.
Well, You're probably right ;) Anyway -
1. Isn't good tradition to support as much as possible and allow administrators to decide, whether they like waste their CPU or not, instead of hardcoding decision in the code?
2. While it probably is a waste of server CPU, analog example with relational database has opposite meaning, as much as I can I'd rather let SQL server do all computations, sorting etc., because I presume, that whatever kind of implementation of e.g. sorting server has, it is better implemented on server code than in my code, because people who created the server are better programmers than I am - I guess. So, I'd bet server developers implemented sorting in better way than I did in my application (ldap client).
Anyway - that's to Jeff especially - worth to note, that openldap client library supports sorting, so in this case "better programmers than me" rule of thumb does not work - client application should use "native" ldap-client sorting (actually implemented on the client side).
?
If you have (for example), a PHP extension, and this extension does not make usage of client-side sorting implemented in ldap-client library it's based on, so you have to sort result on high level, in final script code using some PHP sort function - blame extension authors, and not database server authors.
Finally, as an administrator I'd appreciate server-side sorting in openldap anyway. In my applications I write in C I use openldap's libldap-client sorting and I'm fine with it, anyway, sometimes I'd prefer waste some ldap server CPU, instead of wasting web server CPU (php/perl/other as ldap client). I'd also prefer to waste some ldap server CPU, instead of time spent rewriting something like php ldap extension, or perl ldap binding, or java jndi etc. (AFAIK Java jndi does not support "native" libldap-client sorting too). CPU time, although precious and worthy, is cheaper than programmer's and project manager's time.
Don't take above too seriously, just to discuss :) - anyway I think that's enough reasons to consider implementation server-side sorting. Sometimes I recommend openldap to people searching for corporate catalog solution, beneath Netscape/SUN, IBM's Lotus Directory Server, and (in)famous ActiveDirectory, and others. I use openldap (currently 2.3.39) for many hundreds of users and tens thousands of entries, and I can frankly recommend it. But I don't know what to say, when they say: "But commercial server A supports feature X,Y,Z, and openldap doesn't", and one of features they usually mention first is server-side sorting.
FYI - another feature they mention is ability to return just number of entries found instead of or with entries themselves, as a "part of result", and it's hard to explain, that number of entries is out of ldap server's interest.. :)
Regards, DT