apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <fua...@apache.org>
Subject Re: need a solution with APR DSO
Date Mon, 10 Aug 2009 23:22:21 GMT
Hi,
Bojan Smojver schrieb:
> On Mon, 2009-08-10 at 10:15 -0500, William A. Rowe, Jr. wrote:
>> The idea is to pull in only the bindings used
> 
> Yeah, I thought so too. I kinda remember a discussion along those lines
> on the list...
I'm perfectly fine, and even agree with your both ideas and thoughts as
long as you dont force every developer to adopt them! Why dont you want
to allow developers to choose what's best for their
application/platform? Is that too much freedom??
We'are writing here mail stories about changing / adding few defines
with zero code changes - cant we just agree that it might be useful to
enable / disable DSO build per driver, and not global for all per
APU_DSO_BUILD? What's wrong with my suggestion? Where does it hurt any
other ones? I thought that we just agree about namings of the additional
defines, and then go ahead to change, and really didnt expect that
someone would object to it.

And here again my reasons but more detailed:
On NetWare we have 95% of all httpd/APR users using LDAP(S) - that might
be different on other platforms; but I know this for sure since I was
active as Novell developer sysop for 7+ years, and therefore have a
close view of it. With httpd 2.0.x its 100% of all installations since
httpd 2.0.x is the shipping administration server which is secured
through eDirectory via LDAP(S). In addition Novell provides iPrint,
iFolder, NetStorage httpd modules which all make use of eDirectory via
LDAP. We have a mod_edir which authenticates and fetches home directory
attributes via LDAP. I think these are enough good reasons why we want
to allways have LDAP statically linked.
Another reason which makes my suggestion valid is that we switched in
the middle of lifetime of httpd 2.2.x from APR 1.2.x to 1.3.x - if I
would now build LDAP as DSO this would require additional configuration
to load it, and thus break existing configs - and currently I see
nothing even mentioned in httpd mod_ldap or mod_authnz_ldap about how to
load the ldap 'driver' in case its build as DSO ....

that said, I wish we could just agree that decoupling driver DSO builds
from APU_DSO_BUILD setting is a valid feature request, and wish I could
get some some help with implementing, specially with the configure stuff
for apu_config.h so that I dont break things.

thanks, Gün.



Mime
View raw message