Hi Howard,
Am 08.05.2010 01:11, schrieb Howard Chu:
> Guenter wrote:
>> Novell provides an addon package to OpenLDAP for a wide range of
>> platforms, and this package enhances/simplifies the LDAPS support a lot.
>
> Mmm... Actually LDAPS support in OpenLDAP is dead-easy, you just use
> ldap_initialize(&ld, url) and it does everything necessary regardless of
> the URL type - ldap://, ldaps://, ldapi://, and cldap:// (ldapi is IPC,
> typically over Unix domain socket, and cldap is connectionless LDAP over
> UDP). All of these other APIs are a PITA. You don't need a separate API
> for each type of LDAP connection.
>
> ldap_init() is from the old LDAPv2 API and is deprecated. Any LDAPv3
> compliant SDK should support ldap_initialize().
>
>> Also this package is free/OpenSource as the Novell LDAP SDK too, so you
>> can take it on nearly every platform. However for NetWare OS the Novell
>> LDAP SDK is the only available LDAP client, and thus dropping it would
>> be bad since it would kill LDAP support at all for NetWare. Also for
>> Win32 I use this LDAP SDK too since what M$ ships is too hard to handle
>> for LDAPS.
>
> Hmm. OpenLDAP builds on all of these platforms, you could just use the
> OpenLDAP SDK everywhere.
well, might be that OpenLDAP builds for Novell NetWare - but currently
there are no makefiles (also one reason might be that we have a good
working CLDAP SDK already, so nobody ever tried to re-invent the wheel);
in addition the Berkely DB does not build for NetWare. Might be that it
builds with MingW32 - I failed to get it compiled, and gave up a couple
of times since it was too time-consuming - tried native MSYS environment
as well as cross-compile. I know for sure that OpenLDAP builds with MSVC
- but there are no makefiles / project files either, instead you have to
create this all self. So from my experience and view OpenLDAP is all
other than ready for every platform.

> Anyway, I'm considering leaving the current ldap.c untouched, and
> writing a new openldap.c which only uses the OpenLDAP SDK, just for the
> sake of illustration. OK?
sure; but tell me what's the problem to support more rather than less
LDAP SDKs? Each project might have preferrences for the one or other SSL
library, so why should they not be able to choose the LDAP SDK either? I
believe we should go same direction as we do with SSL support: lets have
one general file ldap.c which does the work, and lets have at least one
other file, f.e. ldapsdk.c where we wrap problematic APIs where the SDKs
differ. BTW IIRC I did build the current code also already against the
Netscape/Mozilla LDAP SDK ...

Gün.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-05-08