[Date Prev][Date Next]
Re: Supported RFC's and "features"
> > 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.. :)