Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.1.2.0.2.20040730033528.0cfa02a0@pop3.rowe-clan.net>
Date: Fri, 30 Jul 2004 05:11:14 -0500
To: dev@apr.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: apr-util/ldap/  -  sink or really swim to 1.0 release?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

First, I'm really fairly happy with where apr 1.0 is, with the only exception
of the aprconfig-1 issue, which I believed was close to a solution.  The
same can't be said for apr-util however :(

I had the misfortune of enabling httpd's modules/experimental/util_ldap.c 
for the Sun LDAP C SDK.  I discovered;

1. we offer an apr_ldap_url_desc_t parser.  That's the only properly
   provisioned/namespace protected code (along w/ accessors to it.)

2. our support doesn't provide -any- assistance in establishing an ldap
   connection to a backend server.  None whatsoever.  util_ldap.d in httpd
   is a nasty and ever expanding mis-mash of ldap-specific ssl create
   connection logic.

3. our support provides one ugly stub for const-ness that actually casts
   args.  This is ---so--- uncool.  The only possibly saving grace is that
   no modern ldap sdk would tickle that code.

4. our APR_HAS_XXX_LDAPSDK macros are entirely bogus, still,
   on unix.

5. we *bogusly* define ldap_memfree and ldap_search_ext_s in the
   *ldap*'s namespace.  This is absolutely incorrect, and will immediately
   cause any ldap-based code to fail once the ldap library is upgraded
   (symbolic duplicates.)


DO WE? ...

A.  Pitch this code from apr-util before someone actually uses it (again)?

B.  Namespace-protect what needs protecting, and actually offer
    useful, abstract ldap create/close connection apr_xxx() fns, with
    registered cleanups for odd exceptions like novell's sdk?

My basic thinking - if httpd's util_ldap.c needs ANY #ifdef magic to
work, we got it wrong in apr-util.  Remove all this cruft back to that
module if we are leaving these decisions to the user.

If we are doing it right, add the accessors, hide the version of ldap
behind the covers, and implement all 'non-portable' behaviors as apr_
flavors of the same.

Reactions?  Suggestions?

Bill