Re: Plea for Server Side Sorting

["Eric Nichols" <eric@dirwiz.com>]

I'm just trying to bring something positive to the table here.  I wouldn't ask
for it unless there was something like an RFC and client ability to use
sorting  to help point the way to a solution.

In my limited logic and knowledge of OpenLDAP/slapd internals...
No matter how complex the query (using indexing or not) there is still
produced a result set.  Maybe someone can enlighten me, but I'm guessing that
result set is stored in memory before it is sent to the client (or paged to
the client).  In that time between the result set being produced and the
result set being sent to the client, can't the records be sorted?

I do not have any doubt in an ldap application wanting to make an API call to
a server... If I am over simplifying please tell me how it can be done, not
how it can't...

I am seriously entertaining a bounty for this code if anyone is interested...

Kurt D. Zeilenga said:
> Second, there are good reasons why sorted results control
> remains unimplemented in slapd(8).
>
> 1) even properly implemented, the sorted results control
> adds little value.  Clients simply cannot rely on the
> servers sorting the results (even where the servers used
> support this control), nor rely terribly on the order of
> results where the servers do sort the result (order in
> many X.500/LDAP match rules is "a local matter"). To
> prove the point, I committed to HEAD a conformant
> implementation of the sorted results control extension
> which doesn't sort a thing.
>
> 2) simple implementations (no indexing support) of this
> control won't scale past a small number of entries, especially
> where other extensions (such as paged results) are involved.
>
> 3) complex implementations (with indexing support) won't
> scale to multiple databases and/or multiple servers because
> of required merging.
>
> I would have serious doubts of any LDAP client which relied
> on LDAP sorted results control.
>
> Kurt