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
--
|