docs/ROADMAP.md

   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