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: Wed, 2 Dec 2020 15:00:43 +0100 (CET)
On Wed, 2 Dec 2020, Patrick Schlangen wrote:
> As especially in embedded environments it might be a goal to keep the
> library footprint as low as possible, how about adding a compile time option
> to be able to toggle this feature on/off, with default being 'on'?
These days, almost every (larger) feature we add is possible to disable at
build-time, I don't think this would be any different. This feature would not
affect embedded users in practise, unless they choose to.
Our modern way of introducing features as experimental first makes it opt-in
at build-time and only once we consider the feature stable and good enough we
toggle that. There is thus a chance to, once there's something to test, figure
out and realize that this isn't a feature we want in the end and just not make
it default - ever.
> (Another mild concern might be that, at least in my understanding, the curl
> binary uses libcurl, but libcurl doesn't 'know' about the curl application.
To me, that's probably one of the bigger philosophical concerns about this
idea. curl uses libcurl, libcurl doesn't know about curl.
But then nobody else than libcurl knows exactly what has been set for a
transfer so only libcurl itself can do a decent conversion...
I'm personally both for and against this idea! =)
Date: Wed, 2 Dec 2020 15:00:43 +0100 (CET)
On Wed, 2 Dec 2020, Patrick Schlangen wrote:
> As especially in embedded environments it might be a goal to keep the
> library footprint as low as possible, how about adding a compile time option
> to be able to toggle this feature on/off, with default being 'on'?
These days, almost every (larger) feature we add is possible to disable at
build-time, I don't think this would be any different. This feature would not
affect embedded users in practise, unless they choose to.
Our modern way of introducing features as experimental first makes it opt-in
at build-time and only once we consider the feature stable and good enough we
toggle that. There is thus a chance to, once there's something to test, figure
out and realize that this isn't a feature we want in the end and just not make
it default - ever.
> (Another mild concern might be that, at least in my understanding, the curl
> binary uses libcurl, but libcurl doesn't 'know' about the curl application.
To me, that's probably one of the bigger philosophical concerns about this
idea. curl uses libcurl, libcurl doesn't know about curl.
But then nobody else than libcurl knows exactly what has been set for a
transfer so only libcurl itself can do a decent conversion...
I'm personally both for and against this idea! =)
-- / 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.htmlReceived on 2020-12-02