Nick Kew wrote:
On Tue, 13 May 2008 09:07:03 +0100
Joe Orton <[EMAIL PROTECTED]> 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 :(
