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: r890580 - in /apr/apr-util/branches/1.4.x: crypto/apr_crypto.c crypto/apr_crypto_nss.c crypto/apr_crypto_openssl.c include/apr_crypto.h include/private/apr_crypto_internal.h test/testcrypto.c
Date Thu, 21 Jan 2010 16:15:56 GMT
On 18 Jan 2010, at 11:23 PM, William A. Rowe Jr. wrote:

> Graham, what's your preference; drop the api from 1.4.1 for  
> extensibility in
> 1.5.0, or go with the 'static' provider model that was previously in  
> 1.4-dev,
> until it's similarly refactored for extensibility with the release  
> of 2.0?
> I think that by waiting 2 months for ssl, we have a lot to win by  
> rethinking
> the underlying ctx's so the crypto cxt references the driver, etc,  
> but I'm
> not to keen on letting it disrupt the release of other new 1.4  
> features
> by yesterday.

We need to keep in mind that all the problems we are so eager to fix  
in apr_crypto have existed in apr_dbd for years, without anyone  
batting an eyelid about it.

While there is definitely merit in delivering a "fixed" apr_crypto  
implementation in v1.4 if such a thing is possible, if it is not  
possible due to our ABI rules I don't think it is necessarily  
something to get too worked up about, as it remains consistent with  
apr_dbd in v1.4.

Given that there have been no strenuous objections to the apr_crypto  
fix on apr-trunk, my plan is to apply the same fix to apr_dbd for  
apr_trunk as well, to bring both APIs into alignment. For obvious  
reasons, this fix to apr_dbd won't be backported to v1.x.


View raw message