On 07 Jul 2011, at 12:44 AM, Igor Galić wrote:
I have already stated the basis for the veto: every single apparent
flaw in the apr_ldap code that caused wrowe to remove it from APR is
still present in the code that wrowe dumped into httpd. If it's not
It is, fortunately, not in httpd's core. It's in mod_ldap.
It makes no difference in this case whether it's in the core or
mod_ldap, it is still an incomplete API, and suffers all the flaws we
suffer right now. What this means practically is that if a module
wants to limit itself to the caching functionality exposed by mod_ldap
that module is fine, but if not, that module has to suffer a load
order problem, and the need to link directly to the LDAP library to
fill in the blanks (mod_authnz_ldap is forced to do this right now).
If the end user installs a module binary linked to a different LDAP
API (mozilla instead of openldap, for example) you get the segfaults
pointed out by sf.
This change does nothing whatsoever to fix the current problems, and
performs no purpose.
There is nothing stopping us addressing these problems in apr-util,
completely within the rules of the APR project, which will fix all our
problems.
good enough for APR, it is not good enough for httpd, period.
As far as we've figured out so far, mod_ldap is the only consumer.
It might not be good enough for APR or httpd, but it's good enough
for mod_ldap.
mod_authnz_ldap is a consumer of both mod_ldap and the direct LDAP
API, as is mod_vhost_ldap, and these are just two modules I know about.
People have been writing modules for httpd and it's derivatives for a
decade and a half, to make a statement like "mod_ldap is the only
consumer" is meaningless. People use our code because they trust our
APIs to remain sensible and stable. This kind of random and badly
thought out change thrust upon the project at the last minute before a
GA release is exactly the kind of the change we don't do at the ASF,
or at httpd.
(Must sleep, more responses over the weekend).
Regards,
Graham
--
