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: need a solution with APR DSO
Date Tue, 11 Aug 2009 15:54:19 GMT
Guenter Knauf wrote:
> Bill,
> William A. Rowe, Jr. schrieb:
>> Guenter, I really missed nothing.  My point was that it consumes
>> process resources to load an ldap support library, which are not
>> needed by all apr consuming applications (in fact, needed only
>> by a tiny minority of applications.)
> I cant resist to think that you somehow dislike LDAP at all ....
> also I disagree with your point of view with 'tiny minority' and '10%
> only'; in fact almost every server platform has an LDAP server running
> (including W2K3), and makes use of it as user database and for access
> control, thus I would more tend to believe that 50% of all APR
> installations making use of LDAP support - at least when httpd is the
> APR consumer; and if I build my own LDAP-aware application upon APR then
> 100% of my users will use LDAP ...
> finally please keep in mind that I dont want to change any defaults - I
> expect 100% same settings and functionality after we have changed what I
> propose; but I want to be able to control DSO/static with a simple edit
> of a define, and without need for patching code at various places.

I have some dozen command line tools (common unix commands) that work more
precisely than their gnuwin tools/unxutils equivilants.  Convince me that
straightforward commands such as which or rm need ldap, or even httpd's
rotatelogs, logresolve or htcacheclean, or Tomcat's tcNative connector.

Loading all libraries for every command executed would be something like
trying to use libtool on Mac OS/X 10.3 PPC, with it's horrid fork() support.
Dog slow.  And unfunny.

"Server Applications" - sure maybe 10% of users try to configure LDAP
at some point, based on user list traffic.  But get it out of your head
that the *only* application of apr[util] is writing server applications :)
We are a bit more utilitarian and useful than that.

View raw message