apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_reslist semantics
Date Tue, 13 May 2008 15:00:00 GMT
Nick Kew wrote:
> On Tue, 13 May 2008 09:07:03 +0100
> Joe Orton <jorton@redhat.com> wrote:
> 
>> changing each function call into
>> an indirected dynamic-symbol-lookup-and-function-call would be an 
>> unmaintainable hack.
> 
> But that's not the proposal on the table!  Noone is suggesting
> changing any function call, API or even ABI.  Merely how the
> code is loaded.

No - nothing will change to the user.  The externally offered symbols
must remain constant, with no change in build procedures for users
who wish to use the 'classic' ldap functionality.

>> 	  Since downstream users must also continue to be 
>> linked against those LDAP libraries by virtue of linking against 
>> libaprutil, it would also be a redundant hack.
> 
> That is a misfeature of the current build procedure.
> I don't see why it can't be changed.  Or indeed left as
> a compile-time option to users, whether to build LDAP
> and other modules as static or dynamic (and in the
> latter case, LDAP support becomes a runtime choice).

Yes; this requires additional stubs because users today must otherwise
continue to bind to ldap directly.  About multiple providers however...

> Dynamic building will be a tremendous aid to anyone
> wanting to support multiple LDAP libraries, too.
> We have some open bugs concerning LDAP that could easily
> be down to static linking and less-than-100%-compatible
> library versions.

My plan was a 1:1 to a specific provider, since this would break
expectations.  I'd agree with Joe that providing multiple LDAP
back-ends would end up being a 2.0 feature :(

Mime
View raw message