apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Date Mon, 06 Jun 2011 22:30:44 GMT
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.


View raw message