Bertrand SIMONNET | e6cd738 | 2015-07-01 15:39:44 -0700 | [diff] [blame] | 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 | isn’t 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 |