Hi, > 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 privately! Guen.
