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 Mon, 18 Jan 2010 21:23:02 GMT
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.

On 1/17/2010 4:52 AM, William A. Rowe Jr. wrote:
> On 12/15/2009 4:57 AM, Graham Leggett wrote:
>> William A. Rowe Jr. wrote:
>>> As I mentioned, the actual contents of the structure are flexible IMHO.
>>> As a user, folks aren't expected to know the difference, but as a developer,
>>> something clearly labeled -alpha should be expected to be changing still.
>>> So if a *developer* coded to any of these API's, well, all bets are off.
>>> But we can leave the apr_crypto_driver_t at the same position as it was
>>> originally in the structure, no?
>> I plan to revert the entire change to v1.4 as you've requested, as
>> making apr_crypto_t private is definitely an incompatible ABI change
>> given that v1.4.x has been released.
>> I can then just focus on v2, where this problem can be fixed properly
>> for dbd and crypto (and then ldap).
> I have another suggestion.
> The correct approach would have started from the correct implementation,
> and we are still missing this by a long shot.  That implementation would
> include the first two members of every crypto context, a pointer to it's
> own apr_pool_t and a pointer to it's own apr_crypto_driver_t, and you would
> not have broken the error lookup function interface.
> I'm going to suggest that the implementation is too immature for apr-util-1,
> and is blocking release of apr-util-1.4.  Everything else is long past done.
> Shipping this correct in apr_util 1.5, even 6 weeks from now, would eliminate
> my concerns over version compatibility created at the httpd project, and
> then give us the flexibility to break these underlying structures to
> properly dereferrence the provider based on the context.
> WDYT?  If you buy this idea, I'll entirely help you fix this interface for
> apr-2 and push forwards to shipping apr-util-1.5, ASAP.  But as you can tell
> from my long silence, I'm stupified at how to resolve this whole condominium
> of fixing a broken interface while preserving ABI.  At least by 1.5 we can
> ensure that there is little chance for a 1.4-pre clash, and do this whole
> thing properly.  You were very close, but weren't at the last mile when that
> 1.4 pre was tagged, unless you want to preserve the fixed-provider ABI.  And
> I think the two of us agree that doesn't serve the purpose of abstracting
> this whole interface.
> Thoughts?

View raw message