Ewww... IIUC - apr_ldap_initialize("ldaps://foo/") was supposed to
handle the ssl 'crap' for us. If we are just exposing OpenLDAP and
Novell LDAP, -1 for this change, and I'd like to propose we deprecate
the whole shooting match for ldap.
Consider apr_dbm. We don't expect or require users to consider the
nuances of each dbm provider, we provide one constant macro. What
apr-util should not become is some binding to require a ton of libs
that the module can do for themselves.
FWIW - I can see functions such as apr_ldap_ssl_key(char*cert, char*ca)
which would require the user to know that cert/ca are symbolic names
on Windows, Sun, etc, and actual file names for OpenLDAP. Some APR_
macro would be required to point this out to the application.
Bill
At 07:24 AM 1/5/2005, you wrote:
>The apr_ldap_option.h interfaces can't be added in a 1.0.x release,
>1.0.x releases must be forward and backwards source-compatible with
>1.0.0 per the versioning guidelines.
>
>I don't know if this one is supposed to be private-but-global or public
>API:
>
>ldap/apr_ldap_init.c: In function `apr_ldap_ssl_init':
>ldap/apr_ldap_init.c:52: warning: implicit declaration of function
>`apr_ldap_ssl_add_cert' ldap/apr_ldap_init.c: At top level:
>ldap/apr_ldap_init.c:110: warning: no previous prototype for
>'apr_ldap_ssl_add_cert'
>
>it should be protototyped (and/or static), or removed from 1.0.x as
>appropriate...
>
>Regards,
>
>joe
