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: r597209 - in /apr/apr-util/trunk: CHANGES build/ssl.m4 include/apr_buckets.h include/apr_ssl.h include/private/apr_ssl_openssl_private.h ssl/apr_ssl_openssl.c ssl/apr_ssl_winsock.c
Date Thu, 22 Nov 2007 18:47:09 GMT
Graham Leggett wrote:
> On Thu, November 22, 2007 5:30 pm, Joe Orton wrote:
>> If I have to know whether apr-util is built against OpenSSL to be able
>> to use this code, it's completely useless.
> It is the same pattern used by mod_ssl, and the existing apr_ssl code, so
> if this is useless, then it is part of a wider problem.

As a general observation, mod_ssl is a good example of library abuse; we
really never leveraged it to do exactly what it does well, after sticking
our fingers into every corner of the library at every layer.

mod_tls was a much better starting point, but mod_ssl was elected because
mod_ssl'ers couldn't do without their favorite features.  Which makes the
compatibility thunks to say, RSA, or far worse, nss or gnutls, somewhere
between uglier and impossible.

I don't want apr_ssl and it's adjuncts to become as polluted as mod_ssl.
Think in terms of implementing today on nss or gnutls, if the user wants
an alternate library provider.  Joe's right, we need it abstracted, or
outright omitted.

We seriously need to start purging anything where apr isn't exposing an
easy migration path of alternate implementation path.  dbd/dbm/ldap do
essentially get this right; xml/xlate essentially get this wrong.  So it's
a matter of which way our apr_ssl will cut, and I'd favor moving it in
the direction of dbd/dbm/ldap so it's not on the apr 2.0 chopping block ;-)

View raw message