1 curl the next few years - perhaps 2 ================================= 3 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. 7 8 HTTP/2 9 ------ 10 11 - test suite 12 13 Base this on existing nghttp2 server to start with to make functional 14 tests. Later on we can adopt that code or work with nghttp2 to provide ways 15 to have the http2 server respond with broken responses to make sure we deal 16 with that nicely as well. 17 18 To decide: if we need to bundle parts of the nghttp2 stuff that probably 19 won't be shipped by many distros. 20 21 - stream properties API 22 23 Provide options for setting priorities and dependencies among the streams 24 (easy handles). They are mostly information set for the stream and sent to 25 the server so we don't have to add much logic for this. 26 27 - server push 28 29 Not exactly clear exactly how to support this API-wise, but by adding 30 handles without asking for a resource it could be a way to be prepared to 31 receive pushes in case such are sent. We probably need it to still specify 32 a URL with host name, port etc but we probably need a special option to 33 tell libcurl it is for server push purposes. 34 35 - provide option for HTTP/2 "prior knowledge" over clear text 36 37 As it would avoid the roundtrip-heavy Upgrade: procedures when you _know_ 38 it speaks HTTP/2. 39 40 - provide option to allow curl to default to HTTP/2 only when using HTTPS 41 42 We could switch on HTTP/2 by-default for HTTPS quite easily and it 43 shouldn't hurt anyone, while HTTP/2 for HTTP by default could introduce 44 lots of Upgrade: roundtrips that users won't like. So a separated option 45 alternative makes sense. 46 47 SRV records 48 ----------- 49 50 How to find services for specific domains/hosts. 51 52 HTTPS to proxy 53 -------------- 54 55 To avoid network traffic to/from the proxy getting snooped on. 56 57 curl_formadd() 58 -------------- 59 60 make sure there's an easy handle passed in to `curl_formadd()`, 61 `curl_formget()` and `curl_formfree()` by adding replacement functions and 62 deprecating the old ones to allow custom mallocs and more 63 64 third-party SASL 65 ---------------- 66 67 add support for third-party SASL libraries such as Cyrus SASL - may need to 68 move existing native and SSPI based authentication into vsasl folder after 69 reworking HTTP and SASL code 70 71 SASL authentication in LDAP 72 --------------------------- 73 74 ... 75 76 Simplify the SMTP email 77 ----------------------- 78 79 Simplify the SMTP email interface so that programmers don't have to 80 construct the body of an email that contains all the headers, alternative 81 content, images and attachments - maintain raw interface so that 82 programmers that want to do this can 83 84 email capabilities 85 ------------------ 86 87 Allow the email protocols to return the capabilities before 88 authenticating. This will allow an application to decide on the best 89 authentication mechanism 90 91 Win32 pthreads 92 -------------- 93 94 Allow Windows threading model to be replaced by Win32 pthreads port 95 96 dynamic buffer size 97 ------------------- 98 99 Implement a dynamic buffer size to allow SFTP to use much larger buffers and 100 possibly allow the size to be customizable by applications. Use less memory 101 when handles are not in use? 102 103 New stuff - curl 104 ---------------- 105 106 1. Embed a language interpreter (lua?). For that middle ground where curl 107 isnt enough and a libcurl binding feels too much. Build-time conditional 108 of course. 109 110 2. Simplify the SMTP command line so that the headers and multi-part content 111 don't have to be constructed before calling curl 112 113 Improve 114 ------- 115 116 1. build for windows (considered hard by many users) 117 118 2. curl -h output (considered overwhelming to users) 119 120 3. we have > 160 command line options, is there a way to redo things to 121 simplify or improve the situation as we are likely to keep adding 122 features/options in the future too 123 124 4. docs (considered "bad" by users but how do we make it better?) 125 126 - split up curl.1 127 128 5. authentication framework (consider merging HTTP and SASL authentication to 129 give one API for protocols to call) 130 131 6. Perform some of the clean up from the TODO document, removing old 132 definitions and such like that are currently earmarked to be removed years 133 ago 134 135 Remove 136 ------ 137 138 1. makefile.vc files as there is no point in maintaining two sets of Windows 139 makefiles. Note: These are currently being used by the Windows autobuilds 140
