On 07 Jun 2011, at 12:53 AM, William A. Rowe Jr. wrote:
Well, exactly. apr_crypto must be reviewed if anyone wants to ship it
in 1.x, apr_ldap and apr_dbd probably don't change in generation 1.x
(not unless there is some hugely compelling reason for backport).
jorton reviewed it first, and all of his requested changes have been
applied where they made sense. jimjag reviewed it a while back and
+1'd it as it stood. That's 3 (including me), just waiting for you to
make it 4.
apr_dbd must be changed prior to apr 2.0 if there is anything we
strongly
believe must be corrected for GA. E.g. nothing can be dropped or
changed
from apr 2.1 (new functions, yes, deprecated, yes, changed, no,
dropped, no).
apr_ldap is new development, it doesn't need to change for apr 2.0.
That
is to say, a fresh apr_ldap can be introduced in apr 2.1 or 2.0. So
it's
just a matter of volunteer time, energy and momentum. In the
interim it
is where it belongs, at it's single consumer.
The only API I am worried about from a backport perspective is
apr_crypto in apr-util v1.4, as it's new. Everything else is apr v2.0
and onwards, as per our API rules.
I am still waiting for your answer to who the other consumers are of
apr_ldap.
No idea. For many years, we have been a general API that offered a
general portability library to any app that wants it, the days of us
being part of httpd are long gone. We set the standard for how APIs
should be managed, and that goes for all of our library.
Regards,
Graham
--
