Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <49C8C874.2010101@apache.org>
Date: Tue, 24 Mar 2009 12:48:04 +0100
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: [VOTE] LDAP in APR 2.x?
References: <5c902b9e0903240326r3222ac90k15dcb7f34d2d1587@mail.gmail.com>
 <cc67648e0903240342p65e17315wbd9e8f78664820af@mail.gmail.com>
 <49C8C4FF.6040604@sharp.fm>
In-Reply-To: <49C8C4FF.6040604@sharp.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 24.03.2009 12:33, Graham Leggett wrote:
> Jeff Trawick wrote:
> 
>> any counter-knowledge/opinions on the following?
>>
>> assert(only httpd uses apr LDAP)
> 
> Can you cite references to show this is so? I would be very hard pressed
> to assert that functionality that has been available in APR for many
> years would have just one single user.

I guess this is also some of the reasons for discussion here: See if others
speak up and say: Hey I need it for my project XY as well.

> There is no way you could ever have two LDAP toolkits in the same
> address space anyway.
> 
> The LDAP C API is a (draft) standard:
> 
> http://www.ietf.org/proceedings/01mar/I-D/ldapext-ldap-c-api-05.txt
> 
> As a result, all LDAP libraries export the same symbols, and therefore
> cannot coexist in the same address space by definition.
> 
> If the initiative to change the LDAP API is an attempt to load two LDAP
> libraries into the server at once, then people need to familiarise
> themselves with the LDAP C API first, before trying to push for major
> surgery to solve a problem we don't have.
> 
> A problem we do have however, is that APR can currently only compile
> against one single LDAP toolkit at a time. This goes against the pattern
> of apr_dbd, where end users can choose from one of many providers.
> 
> I don't see any problem with completely wrapping the LDAP API. It will
> solve the single-LDAP-toolkit problem above.

I guess this would be a very valuable step for keeping it in APR (if not
the only step required). By this we can avoid the consumer of APR to be directly
dependent on the LDAP toolkit by pulling in the LDAP toolkit library
dependencies via the APR library. So it should be possible to compile against
APR with toolkit A and use it on a box that has APR installed compiled against
toolkit B. IMHO that would be a real abstraction of the LDAP interface.
And yes you are correct: You can never use two different LDAP toolkits in
the same process at the same time.
This was also clear from the discussion we had here in Amsterdam but not
mentioned on list yet.

Regards

R�diger