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