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.

Regards,
Graham
--