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