On 03 Jun 2011, at 5:19 AM, William A. Rowe Jr. wrote:
And I am confused with one thing. apr_crypto called out issues
which cause
apr_dbd arg lists to be reevaluated. However, that is not the
complaint with
apr_ldap, but I think you might be conflating them? If the arg
lists to
apr_ldap were an issue, I would have simply proposed the corrections.
apr_ldap has to be refactored, and the standardised part of the API
added, and the biggest risk to this effort is to do all the work, and
then discover that the API is wrong. This is exactly what happened
with apr_crypto. Time is an issue for me as well, I too have bursty
access to time, and once the momentum is going to have that momentum
killed is a big problem.
I believe at the very least, apr_crypto (because it's the newest),
apr_dbd (because it is the template of how we want modular APIs to
work), and apr_ldap (which will be the newest after apr_crypto is
done) should be up to the same consistent standard of API. (I also
believe that this should go further into other bits of apr that depend
on external libraries, but lets get these three nailed first). Given
that apr_crypto is in the soon-to-see-light-of-day apr-util v1.4, and
we don't want to have APIs change unnecessarily, apr_crypto needs to
be perfected first. That's some backports and some polishing away.
Regards,
Graham
--
