>> Ultimately, it will have to get messier because the user will be passing a
>> handle for a private facility instead of just saying, "use the global
>> facility."
>
>I don't understand. Why is
>
> curl_client_use_global(curlc, CURL_GLOBAL_OPENSSL);
>
>"messier" than
>
> curl_client_use_global_openssl(curlc);

That isn't what I was comparing. I meant the as-yet undesigned
interface that will allow one to have a private OpenSSL context will
be messier than the simple url_client_use_global(curlc, XXX) that
works for the global stuff.

But I now realize I was wandering off the path. The whole point of
having private OpenSSL context is that libcurl would, internally,
create its own private OpenSSL context to go with each libcurl client.
So there's no more interface needed.

>Unfortunately that goes pretty much in the opposite direction of my
>efforts to enable libcurl users to be completely unknowing about what
>particular SSL library libcurl uses.

That direction is the direction I'm heading with eliminating global
variables. When libcurl is using private contexts for OpenSSL and
Gnutls, the user won't have to know anything about which SSL facility
is being used inside. Until then, the user is involved in the
difference whether he wants to be or not, and we need facilities that
recognize that.

It will still be true that the simple user of the global libcurl
client (curl_global_init() user) won't need to know which SSL library
it is.

>Yes, but curl-config does not work on all platforms libcurl works on... We
>could perhaps have a function that can return a bitmask with the global flags
>that this particular libcurl uses.

It has to be compile-time. On a system that has no Gnutls installed,
you can't even #include <gnutls/gnutls.h>.

On a system without curl-config, how does one building a curl-using
program know what SSL library to link it with? Or does the SSL
library come automatically with libcurl?

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California