Daniel Stenberg wrote:
Hello Daniel,

> On Thu, 6 Dec 2001, Götz Babin-Ebell wrote:

> > > No. The client code should not use the library's config.h file, it has its
> > > own in src/config.h. Besides, the client code should not need socklen_t and
> > > in_addr_t. Why do your compiler require them?
> >
> > if you configure with --enable-debug, src/main.c and src/urlglob.c
> > include lib/memdebug.h. And in lib/memdebug.h you need at least
> > socklen_t. If you set the #define socklen_t int from config.h in the
> > src/config.h, you don't need need the config.h...
>
> Well, the --enable-debug is a developers-only option and the include of
> lib/memdebug.h from the client code (that it activates) is a kludge in
> itself. We should make sure that it includes the proper includes within that
> file, we should not pollute the client source codes for other conditions.

As I mentioned: (at least I hope I mentioned it...) it was a quick
hack...

> > My changes in the interface of the library:
> > 1. curl_global_init() got an additional parameter: const char *param:
> > a comma seperated list of name=value-pairs,
> > for engine support I have added "CRYPTO_ENGINE=<engine>"
>
> Ugha. We don't want to change this. It would blow compatibility with almost
> every curl-using program out there. Why do we need to specify that already in
> the curl_global_init()? And why do we need a global variable for the
> 'crypto_engine' stuff? Why can't we set that option like we set other options
> with curl_easy_setopt()?

ENGINE_set_default() should be called early in the program.

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

> I'm sorry, but I'm not very familiar with this OpenSSL engine stuff so if my
> questions seem silly, please bear with me.

And I am no member of the OpenSSL core team and I had only a quick look
into
curl. So please bear with me...

> > 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...

> > 2. Since curl_global_init() is called bevore the parameter list is
> > parsed,
> > I added an environmental variable (CURL_INIT_PARAMS).
> > Not good but a fast solution ;-)
>
> Eeeeh. That's just too icky. I don't like that.

Me too...

> Taken all together, I haven't applied your patch yet. There's a few items
> that need to be sorted out first.

Some of these changes might be the result of a misunderstanding of
the curl interface on my side side...
Some of these changes were quick hacks...

Bye

Goetz

-- 
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126