Re: Supported RFC's and "features"

[Piotr Wadas <pwadas@jewish.org.pl>]

> > 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