apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject [PATCH] apr-util/ldap cleanups and Native Win32
Date Sun, 01 Dec 2002 22:04:58 GMT
First off, I'm not certain how APU_HAS_LDAP defined/undefined semantics ever
made it into our library, but it is most wrong.  We use APR_ as our namespace except
internally to apr-util or apr-iconv, and we always use APR_HAS_FOO 1 or 0 as our
markers.  This patch deprecates the APU_HAS_LDAP[_FOO] defined/undefined
semantics, and replaces all that conf gook with legitimate 0|1 values for APR_HAS
flavors of the same.  We should plan to ditch the APU_HAS_foo when we roll out
with APR 1.0.

So I attacked the ldap using native win32 libraries.  Good news; it almost worked.
Bad news; we were missing ldap_url_* api functions.

Only one is used in Apache (the most critical one), ldap_url_parse.  Based on OpenLDAP
this patch offers replacement support for that function alone.  Until someone hollers for
support of ldap_url_search* fn's, I didn't see a reason to bloat.

Of course, this introduces a really interesting question; with or without compiled-in ldap
support, do we want to grok LDAP urls?  I've always been partial to the idea that
apr-util exists to extend apr only in RFC-directed quick-fixes, and this is one (2255).

Anywho; for your consideration.  If any Win32/ldap hackers want to look at this, and
if a NetWare/Unix guru wants to make sure my APU->APR changes made sense,
please do!


View raw message