* The new 'multi' interface is being designed. Work out the details, start
implementing and write test applications!
- [http://curl.haxx.se/dev/multi.h]
-
- * Add a name resolve cache to libcurl to make repeated fetches to the same
- host name (when persitancy isn't available) faster.
+ [http://curl.haxx.se/lxr/source/lib/multi.h]
* Introduce another callback interface for upload/download that makes one
less copy of data and thus a faster operation.
telnet, ldap, dict or file.
* Add asynchronous name resolving. http://curl.haxx.se/dev/async-resolver.txt
+ This should be made to work on most of the supported platforms, or
+ otherwise it isn't really interesting.
+
+ * Data sharing. Tell which easy handles within a multi handle that should
+ share cookies, connection cache, dns cache, ssl session cache.
+
+ * Mutexes. By adding mutex callback support, the 'data sharing' mentioned
+ above can be made between several easy handles running in different threads
+ too. The actual mutex implementations will be left for the application to
+ implement, libcurl will merely call 'getmutex' and 'leavemutex' callbacks.
- * Strip any trailing CR from the error message when Curl_failf() is used.
+ * No-faster-then-this transfers. Many people have limited bandwidth and they
+ want the ability to make sure their transfers never use more bandwith than
+ they think is good.
+
+ * Set the SO_KEEPALIVE socket option to make libcurl notice and disconnect
+ very long time idle connections.
DOCUMENTATION
* Document all CURLcode error codes, why they happen and what most likely
- will make them not happen again.
+ will make them not happen again. In a libcurl point of view.
FTP
already working http dito works. It of course requires that 'MDTM' works,
and it isn't a standard FTP command.
- * Suggested on the mailing list: CURLOPT_FTP_MKDIR...!
-
- * Always use the FTP SIZE command before downloading, as that makes it more
- likely that we know the size when downloading. Some sites support SIZE but
- don't show the size in the RETR response!
+ * Add FTPS support with SSL for the data connection too.
HTTP
http://www.innovation.ch/java/ntlm.html that contains detailed reverse-
engineered info.
- * RFC2617 compliance, "Digest Access Authentication"
- A valid test page seem to exist at:
- http://hopf.math.nwu.edu/testpage/digest/
- And some friendly person's server source code is available at
- http://hopf.math.nwu.edu/digestauth/index.html
- Then there's the Apache mod_digest source code too of course. It seems as
- if Netscape doesn't support this, and not many servers do. Although this is
- a lot better authentication method than the more common "Basic". Basic
- sends the password in cleartext over the network, this "Digest" method uses
- a challange-response protocol which increases security quite a lot.
+ * RFC2617 compliance, "Digest Access Authentication" A valid test page seem
+ to exist at: http://hopf.math.nwu.edu/testpage/digest/ And some friendly
+ person's server source code is available at
+ http://hopf.math.nwu.edu/digestauth/index.html Then there's the Apache
+ mod_digest source code too of course. It seems as if Netscape doesn't
+ support this, and not many servers do. Although this is a lot better
+ authentication method than the more common "Basic". Basic sends the
+ password in cleartext over the network, this "Digest" method uses a
+ challange-response protocol which increases security quite a lot.
+
+ * Pipelining. Sending multiple requests before the previous one(s) are done.
+ This could possibly be implemented using the multi interface to queue
+ requests and the response data.
TELNET
* Make TELNET work on windows98!
+ * Reading input (to send to the remote server) on stdin is a crappy solution
+ for library purposes. We need to invent a good way for the application to
+ be able to provide the data to send.
+
+ * Move the telnet support's network select() loop go away and merge the code
+ into the main transfer loop. Until this is done, the multi interface won't
+ work for telnet.
+
SSL
* Add an interface to libcurl that enables "session IDs" to get
exported/imported. Cris Bailiff said: "OpenSSL has functions which can
serialise the current SSL state to a buffer of your choice, and
recover/reset the state from such a buffer at a later date - this is used
- by mod_ssl for apache to implement and SSL session ID cache"
+ by mod_ssl for apache to implement and SSL session ID cache". This whole
+ idea might become moot if we enable the 'data sharing' as mentioned in the
+ LIBCURL label above.
* Make curl's SSL layer option capable of using other free SSL libraries.
Such as the Mozilla Security Services
(http://www.mozilla.org/projects/security/pki/nss/) and GNUTLS
(http://gnutls.hellug.gr/)
+ LDAP
+
+ * Look over the implementation. The looping will have to "go away" from the
+ lib/ldap.c source file and get moved to the main network code so that the
+ multi interface and friends will work for LDAP as well.
+
CLIENT
* "curl ftp://site.com/*.txt"
the same syntax to specify several files to get uploaded (using the same
persistant connection), using -T.
- * Say you have a list of FTP addresses to download in a file named
- ftp-list.txt: "cat ftp-list.txt | xargs curl -O -O -O [...]". curl _needs_
- an "-Oalways" flag -- all addresses on the command line use the base
- filename to store locally. Else a script must precount the # of URLs,
- construct the proper number of "-O"s...
+ * When the multi interface has been implemented and proved to work, the
+ client could be told to use maximum N simultaneous transfers and then just
+ make sure that happens. It should of course not make more than one
+ connection to the same remote host.
TEST SUITE
projects / platform / upstream / curl.git / commitdiff