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 d...@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 complex.
