>> - A user can't simply skip curl_global_init() because the first
>> curl_easy_init() will do it implicitly.
>
>Right, but that could be changed in a future.
>
>...And I'm quite sure numerous programs are still doing it this "sloppy" way.

For that reason, I don't think we can even consider getting rid of the
implicit curl_global_init(). Curl is too fundamental, and widespread,
to ask people to recode working programs in the name of progress.

>> - Add a new use paradigm for the global-state-averse. libcurl never
>> does any global settings. User can explicitly tell Curl to use
>> global settings he has made separately.
>
>That would mean using CURL_GLOBAL_NOTHING I guess?

No, a user of this paradigm would never call curl_global_init(), and
libcurl wouldn't care. He wouldn't call curl_easy_init(), so the implicit
one would never happen.

>> Where Curl needs global setup and the user hasn't explicitly said
>> to use it, Curl fails.
>
>I believe we might have a hard time to detect the lack of init for
>some cases, so it might have to become an undefined behaviour for
>that situation.

I see no reason to try to detect lack of init. The user is responsible for
doing the necessary global init. If he doesn't, and tells us that he did,
that's the same as when he hands us something he says is a CURL handle, but
is really uninitialized memory. (I.e. undefined behavior).

>The big problem with this approach however, is that we
>have a whole bunch of functions in libcurl that don't take any easy or multi
>handle as input, so thus we'd have to change the API for many functions (or
>add cloned functions with the only diff that they take such a handle as
>argument).

I will take a careful look at all the functions. The only ones that
matter are ones that access sockets, use idna, or allocate memory. If
there are lots of those, I may need to get a different big picture.

In any case, I am reluctant to make any change that makes old programs
not compile with the new libcurl. I would rather add new functions
and deprecate the old ones.

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