1 curl the next few years - perhaps
2 =======================
4 Roadmap of things Daniel Stenberg and Steve Holme want to work on next. It is
5 intended to serve as a guideline for others for information, feedback and
6 possible participation.
13 2. http2 multiplexing/pipelining
21 6. make sure there's an easy handle passed in to curl_formadd(),
22 curl_formget() and curl_formfree() by adding replacement functions and
23 deprecating the old ones to allow custom mallocs and more
25 7. HTTP Digest authentication via Windows SSPI
27 8. GSSAPI authentication in the email protocols
29 9. add support for third-party SASL libraries such as Cyrus SASL - may need to
30 move existing native and SSPI based authentication into vsasl folder after
31 reworking HTTP and SASL code
33 10. SASL authentication in LDAP
35 11. Simplify the SMTP email interface so that programmers don't have to
36 construct the body of an email that contains all the headers, alternative
37 content, images and attachments - maintain raw interface so that
38 programmers that want to do this can
40 12. Allow the email protocols to return the capabilities before
41 authenticating. This will allow an application to decide on the best
42 authentication mechanism
44 13. Allow Windows threading model to be replaced by Win32 pthreads port
46 14. Implement a dynamic buffer size to allow SFTP to use much larger buffers
47 and possibly allow the size to be customizable by applications. Use less
48 memory when handles are not in use?
53 1. Embed a language interpreter (lua?). For that middle ground where curl
54 isn’t enough and a libcurl binding feels “too much”. Build-time conditional
57 2. Simplify the SMTP command line so that the headers and multi-part content
58 don't have to be constructed before calling curl
63 1. build for windows (considered hard by many users)
65 2. curl -h output (considered overwhelming to users)
67 3. we have > 160 command line options, is there a way to redo things to
68 simplify or improve the situation as we are likely to keep adding
69 features/options in the future too
71 4. docs (considered "bad" by users but how do we make it better?)
72 A - split up curl_easy_setopt.3
75 5. authentication framework (consider merging HTTP and SASL authentication to
76 give one API for protocols to call)
78 6. Perform some of the clean up from the TODO document, removing old
79 definitions and such like that are currently earmarked to be removed years
85 1. cmake support (nobody maintains it)
87 2. makefile.vc files as there is no point in maintaining two sets of Windows
88 makefiles. Note: These are currently being used by the Windows autobuilds