On Thu, 6 May 2004, Gisle Vanem wrote:

> Correct me if I'm wrong, but it seems curl_connect() is called to create a
> tcp socket etc. before curl_ldap() (i.e. conn->curl_do).

Yes, that's right. The flow goes like this:

 1. CONNECT
   Makes a TCP connection and allows a protocol-specific function to run.

 2. DO
   Sets up a request for a transfer (using a protocol-specific function)

 3. TRANSFER
   Is meant to work for multiple protocols but is currently swamped with HTTP
   details.

 4. DONE
   Whatever needs to be done after a transfer is finished. Offers a protocol-
   specific function.

 5. DISCONNECT
   Called when the connection to the server is closed. Offers a protocol-
   specific function.

(and outside of these are Curl_open() and Curl_close() that open and close the
entire curl handle, Curl_close() can be made to call a protocol-specific
function for clearing up protocol-specific stuff related to this handle.)

> Since the ldap libraries does all this themselves, why would libcurl need to
> connect() too?

If the LDAP library has a connect function, it would be called in its
ldap-specific connect-function. But I agree that the generic connect function
does a little too much for the LDAP and FILE cases, and possibly for others.

Fixing this would probably make sense.

> I'm toying with the idea to add a snmp handler, but this needs UDP. So is
> there a way to let 'conn->curl_do' do all the stuff itself? (and libcurl
> just the url parsing etc.).

The current generic Curl_connect() code outside the protocol-specifics could
be converted to a Curl_tcp_connect() instead, and then we call that function
from within the HTTP and FTP functions (and what else) that need TCP to
connect. The each protocol decides on its own how to connect to its host.

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html