apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <fua...@apache.org>
Subject Re: LDAP over SSL on Win32
Date Thu, 20 Mar 2008 22:21:48 GMT
> Isn't the point, though, for APR to *SOLVE* such problems?  If we aren't,
yes, but where stands written _how_ to solve?
Isnt it just the same as what we do with OpenSSL? Otherwise for me the question arises why
we dont rewrite the SSL support to use Win32's own SSL stack (schannel or whatever its called)
in order to avoid OpenSSL dependency? Here we go the simple way and just use OpenSSL because
its known to work reliable on all platforms including Win32 - now you even tell me that Covalent
does think same about OpenLDAP - so what speaks against supporting LDAP(S) through OpenLDAP
instead of messing around with the MS implementation?

> I'm strongly +1 for removing ldap from apr-util; we simply bring next to
> no value to the end user because they are wired too closely to the stack,
> and we haven't abstacted it enough to justify even keeping it.
+0.5 from my side since the benefit of having it in apr-util isnt clear to me, however not
thought to the end;
but dropping LDAP(S) support only because we need to depend on another external (non-OS) lib
is no reason for me...
I think the greatest advantage would be to have a library-less LDAP(S) support = own code
which only uses our APR sockets.
Would be a nice GOS project.....

>> at least we should make it switchable for the Win32 build, and that
>> shouldnt be much trouble since we have full support for this SDK already
>> in due to the NetWare port using it.

> No-go unless we want pluggable LDAP providers just as we have
sorry, but this I dont understand; can you explain some more?

>> Although OpenLDAP would be an option too - I'm not aware of any MSVC
>> port;

> Hmmm... builds fine here :)  As I say - this is what my customers use.
well, that sounds very great, and if you also have a MSVC6 build around then please send me


View raw message