moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2025-03-03 10:51:49 -05:00
Code Issues Releases Wiki Activity

TODO: remove items for next SONAME bump etc

Browse Source 
We want to avoid that completely, so we don't plan for things after such
an event.
This commit is contained in:
Daniel Stenberg 2021-02-02 08:46:37 +01:00
parent fc9d3444d1
commit fc9dd2d198
No known key found for this signature in database
GPG Key ID: 5CC908FDB71E12C2
1 changed files with 0 additions and 113 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

113
docs/TODO
View File

@ -185,20 +185,6 @@
20.8 Run web-platform-tests url tests
20.9 Use "random" ports for the test servers
21. Next SONAME bump
21.1 http-style HEAD output for FTP
21.2 combine error codes
21.3 extend CURLOPT_SOCKOPTFUNCTION prototype
22. Next major release
22.1 cleanup return codes
22.2 remove obsolete defines
22.3 size_t
22.4 remove several functions
22.5 remove CURLOPT_FAILONERROR
22.7 remove progress meter from libcurl
22.8 remove 'curl_httppost' from public
==============================================================================
1. libcurl
@ -1310,102 +1296,3 @@
We could then remove the "check that it is our server that's running"-check
and we would immediately detect when we write tests wrongly to use hard-coded
port numbers.
21. Next SONAME bump
21.1 http-style HEAD output for FTP
#undef CURL_FTP_HTTPSTYLE_HEAD in lib/ftp.c to remove the HTTP-style headers
from being output in NOBODY requests over FTP
21.2 combine error codes
Combine some of the error codes to remove duplicates. The original
numbering should not be changed, and the old identifiers would be
macroed to the new ones in an CURL_NO_OLDIES section to help with
backward compatibility.
Candidates for removal and their replacements:
CURLE_FILE_COULDNT_READ_FILE => CURLE_REMOTE_FILE_NOT_FOUND
CURLE_FTP_COULDNT_RETR_FILE => CURLE_REMOTE_FILE_NOT_FOUND
CURLE_FTP_COULDNT_USE_REST => CURLE_RANGE_ERROR
CURLE_FUNCTION_NOT_FOUND => CURLE_FAILED_INIT
CURLE_LDAP_INVALID_URL => CURLE_URL_MALFORMAT
CURLE_TFTP_NOSUCHUSER => CURLE_TFTP_ILLEGAL
CURLE_TFTP_NOTFOUND => CURLE_REMOTE_FILE_NOT_FOUND
CURLE_TFTP_PERM => CURLE_REMOTE_ACCESS_DENIED
21.3 extend CURLOPT_SOCKOPTFUNCTION prototype
The current prototype only provides 'purpose' that tells what the
connection/socket is for, but not any protocol or similar. It makes it hard
for applications to differentiate on TCP vs UDP and even HTTP vs FTP and
similar.
22. Next major release
22.1 cleanup return codes
curl_easy_cleanup() returns void, but curl_multi_cleanup() returns a
CURLMcode. These should be changed to be the same.
22.2 remove obsolete defines
remove obsolete defines from curl/curl.h
22.3 size_t
make several functions use size_t instead of int in their APIs
22.4 remove several functions
remove the following functions from the public API:
curl_getenv
curl_mprintf (and variations)
curl_strequal
curl_strnequal
They will instead become curlx_ - alternatives. That makes the curl app
still capable of using them, by building with them from source.
These functions have no purpose anymore:
curl_multi_socket
curl_multi_socket_all
22.5 remove CURLOPT_FAILONERROR
Remove support for CURLOPT_FAILONERROR, it has gotten too kludgy and weird
internally. Let the app judge success or not for itself.
22.7 remove progress meter from libcurl
The internally provided progress meter output doesn't belong in the library.
Basically no application wants it (apart from curl) but instead applications
can and should do their own progress meters using the progress callback.
The progress callback should then be bumped as well to get proper 64bit
variable types passed to it instead of doubles so that big files work
correctly.
22.8 remove 'curl_httppost' from public
curl_formadd() was made to fill in a public struct, but the fact that the
struct is public is never really used by application for their own advantage
but instead often restricts how the form functions can or can't be modified.
Changing them to return a private handle will benefit the implementation and
allow us much greater freedoms while still maintaining a solid API and ABI.