Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl_easy_cmdline ?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 3 Dec 2020 23:38:50 +0100 (CET)
On Thu, 3 Dec 2020, Timothe Litt via curl-library wrote:
Thanks Timothe, you really took this further!
> int curl_easy_getopt(CURL *handle, CURLoption option, size_t
> bufsize, void *buffer)
>
> Returns any settable option's current value in buffer, with the
> same type as curl_easy_setopt(). Returns CURLE_UNKNOWN_OPTION,
> CURLE_NOT_BUILT_IN, CURLE_OVERFLOW, or CURLE_OK. OVERFLOW if
> buffer too small for value.
I like the core of your thinking here, but I don't think exposing a function
this "raw" for exporting the contents of a single option will do a lot of good
and the API is much too crude and error-prone when people will try to extract
the values from that buffer. And I would bet good money that people would.
> curl_easy_write_handle_state(CURL *handle, FILE *fh), where fh is
> open in binary mode.
This function however, seems much more like the golden middle-way worth
exploring further.
Extracting all the contents from an easy handle to a well-documented binary
format would be much less code than the *cmdline() version, it would remove
the libcurl-to-curl mapping that none of us were really comfortable with and
it could rather allow a "binary-to-cmdline" tool/option to be created and to
be fancy and without the restrictions a library function would have.
I can also predict that binding authors and others would rather have the
ability to get that "snapshot" put into a buffer in memory to avoid storing
temp files...
> curl --gencmd statefile
>
> curl --genxml statefile
Right. And --gencmd combined with --libcurl would get the C program for it...
=)
> This would make a pass over curl_easy_listopt to obtain the mapping
> of codes to names and types.
Note that we already provide curl_easy_option_next(), which can iterate over
all known easy options and return info about them. And
curl_easy_option_by_id() to look up an option by its id. So a lot of pieces
are already there...
> The curl_easy_getopt function has other uses - e.g. it can eliminate the
> requirement for an application to keep its own copy of dynamic values.
It can indeed, but to do that in a good way it would need to return the data
in a way that the caller wants it and is unlikely to get wrong.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-03
Date: Thu, 3 Dec 2020 23:38:50 +0100 (CET)
On Thu, 3 Dec 2020, Timothe Litt via curl-library wrote:
Thanks Timothe, you really took this further!
> int curl_easy_getopt(CURL *handle, CURLoption option, size_t
> bufsize, void *buffer)
>
> Returns any settable option's current value in buffer, with the
> same type as curl_easy_setopt(). Returns CURLE_UNKNOWN_OPTION,
> CURLE_NOT_BUILT_IN, CURLE_OVERFLOW, or CURLE_OK. OVERFLOW if
> buffer too small for value.
I like the core of your thinking here, but I don't think exposing a function
this "raw" for exporting the contents of a single option will do a lot of good
and the API is much too crude and error-prone when people will try to extract
the values from that buffer. And I would bet good money that people would.
> curl_easy_write_handle_state(CURL *handle, FILE *fh), where fh is
> open in binary mode.
This function however, seems much more like the golden middle-way worth
exploring further.
Extracting all the contents from an easy handle to a well-documented binary
format would be much less code than the *cmdline() version, it would remove
the libcurl-to-curl mapping that none of us were really comfortable with and
it could rather allow a "binary-to-cmdline" tool/option to be created and to
be fancy and without the restrictions a library function would have.
I can also predict that binding authors and others would rather have the
ability to get that "snapshot" put into a buffer in memory to avoid storing
temp files...
> curl --gencmd statefile
>
> curl --genxml statefile
Right. And --gencmd combined with --libcurl would get the C program for it...
=)
> This would make a pass over curl_easy_listopt to obtain the mapping
> of codes to names and types.
Note that we already provide curl_easy_option_next(), which can iterate over
all known easy options and return info about them. And
curl_easy_option_by_id() to look up an option by its id. So a lot of pieces
are already there...
> The curl_easy_getopt function has other uses - e.g. it can eliminate the
> requirement for an application to keep its own copy of dynamic values.
It can indeed, but to do that in a good way it would need to return the data
in a way that the caller wants it and is unlikely to get wrong.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-03