diff options
author | Daniel Stenberg <daniel@haxx.se> | 2007-11-26 12:26:58 +0000 |
---|---|---|
committer | Daniel Stenberg <daniel@haxx.se> | 2007-11-26 12:26:58 +0000 |
commit | ebce0a16f6b2587434ba5bcde5b40633bb17c54c (patch) | |
tree | 5e1a2066c235fce55af0fc9c19f210f59b2f6941 /docs/INTERNALS | |
parent | df546bd58c176f20c3e2e025c46e7d254ea08ea6 (diff) |
more blurb
Diffstat (limited to 'docs/INTERNALS')
-rw-r--r-- | docs/INTERNALS | 41 |
1 files changed, 41 insertions, 0 deletions
diff --git a/docs/INTERNALS b/docs/INTERNALS index f3769b1fd..84538a931 100644 --- a/docs/INTERNALS +++ b/docs/INTERNALS @@ -289,6 +289,40 @@ Persistent Connections You do realize that the curl handle must be re-used in order for the persistent connections to work. +multi interface/non-blocking +============================ + + We make an effort to provide a non-blocking interface to the library, the + multi interface. To make that interface work as good as possible, no + low-level functions within libcurl must be written to work in a blocking + manner. + + One of the primary reasons we introduced c-ares support was to allow the name + resolve phase to be perfectly non-blocking as well. + + The ultimate goal is to provide the easy interface simply by wrapping the + multi interface functions and thus treat everything internally as the multi + interface is the single interface we have. + + The FTP and the SFTP/SCP protocols are thus perfect examples of how we adapt + and adjust the code to allow non-blocking operations even on multi-stage + protocols. The DICT, TELNET and TFTP are crappy examples and they are subject + for rewrite in the future to better fit the libcurl protocol family. + +SSL libraries +============= + + Originally libcurl supported SSLeay for SSL/TLS transports, but that was then + extended to its successor OpenSSL but has since also been extended to several + other SSL/TLS libraries and we expect and hope to further extend the support + in future libcurl versions. + + To deal with this internally in the best way possible, we have a generic SSL + function API as provided by the sslgen.[ch] system, and they are the only SSL + functions we must use from within libcurl. sslgen is then crafted to use the + appropriate lower-level function calls to whatever SSL library that is in + use. + Library Symbols =============== @@ -312,6 +346,13 @@ Return Codes and Informationals them. They are best used when revealing information that isn't otherwise obvious. +API/ABI +======= + + We make an effort to not export or show internals or how internals work, as + that makes it easier to keep a solid API/ABI over time. See docs/libcurl/ABI + for our promise to users. + Client ====== |