apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
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 18:11:19 GMT
On 1/21/2010 10:15 AM, Graham Leggett wrote:
> 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.

You are absolutely right, I made this comment on dev@httpd yesterday, that
too many bad API examples are in the library today.

This suggests that dbd was not given adequate oversight coming into apr.
That shouldn't suggest that less oversight now applies.

Folks using dbd will be rudely interrupted in apr-2.0 with the need to
modify their code for conforming api names and arguments.  I don't want
that to happen to users of apr_crypto_*, if it can be avoided.

There are still several flaws with the crypto API on trunk, I'm looking
forward to fixing these as part of a general review, not singling out
crypto.  If we can wait a month to release 1.5.0 with crypto, then they
will have no 'interruption' in their use of that API; it will take me
some time to complete this entire review and present the conclusions to
this list.

There is lots of data to crunch with respect to the apr-2.0 API, accounting
for all prototypes that exist in include/*.h today.  The project seems to
have paid much less attention to what went into apr-util, than into apr the
main library, which makes the amount of work in this review even more

View raw message