Guenter wrote:
> 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);

Probably true.

> in addition the Berkely DB does not build for NetWare.

BerkeleyDB is only used by the server, we're only talking about libldap here.

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

Hm, OpenLDAP builds cleanly for me using MinGW/MSYS. But anyway, this is all
digression.

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

None of the other existing LDAP SDKs has been updated much in the past 10 years.

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

http://mail.opensolaris.org/pipermail/sparks-discuss/2008-August/000521.html

Netscape is dead, and Mozilla has been steadily dropping support for LDAP in
their code base. (E.g., the Netscape browser used to process ldap:// URLs and
render the results in pretty-printed HTML. None of that code remains in the
current Mozilla code base. It is for all intents and purposes abandonware.)

Anyway, the code in this patch is fully asynchronous. You can't accomplish
this with any of the older SDKs.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html