I've looked further into the global variable issue, and it got more
complicated. Here are some additional observations:

- A user can't simply skip curl_global_init() because the first
  curl_easy_init() will do it implicitly.

- A user doesn't generally know whether libcurl will want to use SSL, and
  worse, even if he does, he doesn't know whether libcurl will use OpenSSL
  or GNU TLS.
  
- The Windows setup is equivalent to all the other global variable things.
  We should probably say global state instead, because there aren't
  necessarily C variables in memory involved. WSASetup() allocates
  resources for the process and sets up state that is shared by every
  user of sockets in the process. You have to do WSASetup() before
  the first use of sockets anywhere in the program and do WSACleanup()
  not before the last use.

So here's a new proposal.

  - Document in more detail the global state issue, but still require
    curl_global_init(). You can use global_init's flags to skip
    things that you have set up separately. All existing happy users
    continue to do what they're doing.

  - 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. Where Curl needs global
    setup and the user hasn't explicitly said to use it, Curl fails.
    To wit:

    - A new object called a "Curl client." It records:

      - Curl memory allocator functions.

      - User's request that libcurl use his global setup of Windows
        sockets, Amiga sockets, CHARSET global variable, OpenSSL, or
        GNU TLS.

    - A new constructor for the CURL object, curl_easy_init_c(), takes
      a Curl client as an argument. Every CURL object is linked to a
      Curl client. Same for multi object.

    If it's Windows or Amiga, and the user doesn't say it's OK to use
    the global socket setup, this constructor fails. If an operation
    requires use of an SSL library, and the user didn't say he has set
    up the required library, the operation fails as if there were no
    SSL library linked.

    In the future, we will have an SSL library that similarly doesn't
    have global state. In that case, if the user doesn't say to use
    the global SSL library setup, curl_easy_init_c() would create an
    SSL "client object" and attach it to the Curl client. And the SSL
    Curl operations would work.

    In theory, every other one of those global state things could be
    fixed in the lower layer some day, and libcurl would be ready to
    take advantage.

    For backward compatility, there is a global Curl client, created
    by curl_global_init() and pointed to by a global variable.
    curl_easy_init() associates the global client with the CURL object.

Any good? I'm willing to develop the prototype of this.

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