On Mon, 10 Dec 2001, Götz Babin-Ebell wrote:

> > > 1. curl_global_init() got an additional parameter: const char *param:
>
> > Ugha. We don't want to change this. It would blow compatibility with
> > almost every curl-using program out there.
>
> ENGINE_set_default() should be called early in the program.

"early" as in how early? Isn't it enough if done before we create the SSL
"context"? (Which we do in lib/ssluse.c:Curl_SSLConnect)

> Perhaps some additional curl_easy_setopt() options:
>
> 1. CURL_SSL_ENGINE_NAME:
> parameter: engine name
> load an ENGINE and set it to the data structures...
> calls ENGINE_set_default()
> 2. CURL_SSL_ENGINE_NAME2:
> like 1. but don't call ENGINE_set_default()
> (for second session...)
> 3. CURL_SSL_SET_ENGINE
> parameter: pointer to an ENGINE
> sets this as ENGINE
> 4. CURL_SSL_GET_ENGINE
> parameter: pointer to a memory area that will get the actual
> ENGINE pointer

Ok, here's a whole range of questions coming up. I'm just so clueless here.

What exactly is an "ENGINE" in the (Open)SSL sense?

What's the difference between CURL_SSL_ENGINE_NAME2 and CURL_SSL_SET_ENGINE
in your suggestion above? Why do we need two "ENGINE_NAME*" options?
Shouldn't curl itself keep track of which engines it has loaded and keep the
user unknowing and uncaring only to decide which one to actually use? So

Why would anyone like to get to know the "actual ENGINE pointer"
(CURL_SSL_GET_ENGINE)?

> > > 2. curl_global_init(): additional flag CURL_GLOBAL_SSL_XTRN:
> > > signaling the ssl submodule that OpenSSL is initialized external
> > > and no init is needed.
> >
> > Which then would be the complete opposite of the CURL_GLOBAL_SSL option
> > and I can't see why CURL_GLOBAL_SSL_XTRN is needed then. Can't you just
> > not use CURL_GLOBAL_SSL instead?
>
> From a glance in the code I belived you have to call Curl_SSL_init() to use
> the SSL functionality. But now I don't find the reference...

The libcurl user calls curl_global_init() with the appropriate flags. If done
correctly, and the library is build with SSL support, libcurl will itself
call its internal function Curl_SSL_init(). That's correct.

But it also means that you can set the flags to *NOT* init OpenSSL by
specifying only flags that aren't related to SSL (in a manner similar to:
curl_global_init(~CURL_GLOBAL_SSL);). That'll give the same effect your
suggested CURL_GLOBAL_SSL_XTRN flag has. If I'm not misunderstanding you
here.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/