On Sat, Nov 17, 2001 at 11:22:21PM +0100, Andre Oppermann wrote:
> Stig Venaas wrote:
> > In what LDAP APIs are ldap_sort_entries defined? What lib/API are you
> > using? I wonder how well this works, sorting all kinds of Unicode is
> > more or less impossible, but if some APIs have this function...
>
> This function is supported by OpenLDAP 1.x/2.x, UMICH and Netscape
> SDK as well.
Ah, okay, didn't know, maybe because it isn't mentioned in the specs.
I'm much more positive then.
> Unicode is no problem because you can specify your own comparsion
> function callback (the last parameter "strcmpncase").
Yes, I realized after my post. But isn't this a problem for us? We might
have to allow for people to define their own PHP callback function. I
could fix that, if that's what we want. We could add that as an optional
parameter later perhaps. The way UTF-8 behaves, I guess sorting order is
the same before and after decoding, if not, this function doesn't make
much sense (except when ascii-only being used). You have experiences with
German umlauts perhaps? But for simple things like Norwegian (and I know
others), the special character values are not in alphabetical order, so
this function isn't going to do the job perfectly, a userdefined function
might.
> > I was also thinking of adding support for server side sorting. I'm
> The problem with server side sorting is that it is a LDAPv3 only
> function and there is no requirement that LDAP server implements
> this.
Yes, and if you want all entries, it makes more sense to do it in the
client.
>
> > thinking of a different PHP API, so that we don't need to add even
> > more parameters to ldap_search(). Adding parameters to ldap_search()
>
> I added it only to ldap_search() because only there I have access to
> the full LDAPMessage chain. The function needs **ldap_res, not just
> the *ldap_res that is delivered by that internal function in PHP.
>
> > that only are valid with some APIs is bad I think. What I have in
> > mind is something like:
>
> ldap_search is valid with basically every ldap lib out there.
I meant parameters that are only valid in some APIs, of course
ldap_search is.
> > ldap_sort($ld, $sortfilter);
> > ldap_search($ld,...); (as usual)
> >
> > where the filter is used for all following searches, until a new filter
> > is defined. Empty filter could turn it off.
>
> Until now the right thing to do (see ldapsearch tool in OpenLDAP/UMICH)
> to do this:
>
> ldap_search($ld,...);
> ldap_sort($ld, $res, $sortlist, [OPT_UNICODE | WHATEVER]);
What I wrote with ldap_sort() and ldap_search() was PHP code. I suggest
we write a separate ldap_sort() that works this way. ldap_sort() can
then store stuff in the PHP link structure. Inside PHP's ldap_search()
function, we then check for this after we've done the search. So it
will be very much like your code, except that instead of an extra
parameter for PHP's ldap_search(), we use a separate ldap_sort() to set
it. We can then also add advanced features like user defined callback
more easily.
> Well, there no problem in providing both API. The ldap_sort() call is
> useable today with all ldap libs and with any LDAP server. Server side
> sorting is nice if you have LDAPv3 and your server supports it.
Of course server side sorting also has the ordering issues I mentioned
above. It's mostly impossible to write server side sorting that always
sorts things the right way. Language tags might help. Well, forget this.
I'll add some code for this in a few days, then you can comment on what
I've done. Not that I mind discussing this (:
Stig