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: svn commit: r799085 - /apr/apr/trunk/apr-config.in
Date Wed, 05 Aug 2009 14:48:29 GMT
Graham Leggett wrote:
> Ruediger Pluem wrote:
>>> URL: http://svn.apache.org/viewvc?rev=799085&view=rev
>>> Log:
>>> Drop incomplete abstrations from apr-2.0; for today, simply omit the ability
>>> to inspect ldap linkage binding.
>>> apr_ldap either needs to be refactored as a proper abstration or dropped from
>>> the apr 'suite' of portability abstractions, as previously discussed on list.
>>> This commit might encourge some forward progress to accomplishing this.
>>> Note there is nothing wrong with abstracting our build/autogunk m4 macros
>>> to the point where authors can borrow the logic when they want an apr-ish
>>> method of picking one of many interfaces.
>>> Modified:
>>>     apr/apr/trunk/apr-config.in
>> This breaks compilation of httpd trunk with apr trunk if you want to compile
>> the httpd ldap modules.

Yes.  This behavior is by design.

> Which is in turn a prerequisite for anyone wanting to develop the ldap
> stuff further. Please revert.

Anyone wanting to develop and ldap abstraction is welcome to do so!!!

You hit the nail on the head.  The previous api is "ldap stuff".  As in,
we want more stuff.  The problem is, until we start cleaning up and
arranging the stuff, we will not get anywhere.

Anyone wanting apr-util ldap library detection .m4 code, can borrow that.
It's under Apache License.  They can do so now and refresh whenever, just
as they can borrow our own recommended apr library detection code.

> This change only makes sense to do if apr-2.0 becomes ready for actual
> release, and we're not anywhere near there yet.

Right, we can't release 2.0 because it's namespace is not clean, because
things such as raw ldap bindings are still provided, and that isn't APR's
job (refer to all other APIs for similar issues).

The LDAP proponents have all agreed over a year ago that this should be
done. There was absolute refusal initially, until the benefit of plugging
in alternate ldap providers/SDKs became interesting and solving many
'unexpected' results and return codes (bugs) became an issue.

apr-2 is, as you say, nowhere near release for a month or few.  So in the
meantime, the developers who would be helping to make it ready need to be
prepared for what changes, and this changes.  Those who need ldap right now
to transition ldap to apr as they develop the ldap api know how to -lldap.

The technical veto is that the module which allocates resources must have
the corresponding interfaces to release them.  Right now ldap resources
are allocated by ldap and apr_ldap, and freed by apr_ldap and the consumer.
This is not good.

But that's my argument.  We will settle with a vote.


View raw message