On Sat, 5 Jan 2013, Philip Montrowe wrote:
I was thinking more along the lines of adding an exit similar to
CURLOPT_SSL_CTX_FUNCTION and CURLOPT_SSL_CTX_DATA like so:
I really prefer not to. Strongly.
libcurl is 99% SSL library agnostic in its API and use. We try very hard to
provide a single and stable API and ABI to applications so that they won't
have to care about things like which SSL library libcurl uses.
CURLOPT_SSL_CTX_FUNCTION is an exception to that rule. It is unfortunate and
it hurts users - but as we can't and won't remove it, we can certainly strive
to not repeat that mistake and dig our hole even deeper.
Our task is to REDUCE the SSL-specific stuff from our API, not the other way
around.
So, back to the subject at hand: I suggested a way that could offer a
consistent API independently of the SSL backend. Is there a particular reason
that wouldn't work?
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
