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 Sun, 17 Jan 2010 10:52:09 GMT
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.


View raw message