Buy commercial curl support. 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 Daniel himself.
Re: Thoughts about upstreaming wcurl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 4 Jul 2024 11:51:04 -0700
As it is, I don't think wcurl adds substantial enough value to carry along
upstream. Right now, it doesn't do much beyond setting a few standard options
on curl itself, which people can do themselves already in a number of different
ways to suit them.
You mention a few possible improvements, but there seems to be a lack of
clarity of what wcurl is supposed to be. Is it a more simple interface to curl
for certain use cases? Is it a low-resource way to access curl functionality
with a wget interface? Is it a wget replacement rewritten from the ground up
using libcurl to perform transfers?
When I saw the announcement, I thought it was the second case, namely a way for
people used to wget to run curl. It wouldn't add functionality that curl didn't
already have, but it would give access to what it DID have in a familiar way.
I talked about this a bit on IRC, since this is an idea I've had for a long
time that I've never acted on. My idea was that a small script would translate
options for features that curl already supports and just call curl to perform
the transfer in the end. So --bind-address would be translated to --interface,
--no-clobber would translate to --skip-existing, --https-only would translate
to "--proto -all,https", etc. And the options (like -r) that curl doesn't
support would cause an error.
As it is, the current wcurl doesn't do that and can't do that because its only
current option (-o) is already defined by both wget and curl in completely
different and incompatible ways. So, given that, I don't really see what the
path forward is for further wcurl improvements, unless it just becomes a third
new utility for performing network transfers.
I personally think that second case hits a sweet spot in that it adds
significant functionality (a new user interface for curl) that many people are
familiar with in only a few KB of space without significant portability
concerns (although it sounds like the getopt issue needs to be solved). That
would be a Busybox-style approach to wget functionality. Actually, Busybox
already supports a "wget" applet, but reimplemented the Busybox way and only
supporting 14 options. A curl version could support many, many more wget
options and would probably take even less space, if we assume that curl is
already available.
The third case (wget reimplemented) would be better as a separate project since
its added functionality strays away from what curl is trying to be.
Dan
Date: Thu, 4 Jul 2024 11:51:04 -0700
As it is, I don't think wcurl adds substantial enough value to carry along
upstream. Right now, it doesn't do much beyond setting a few standard options
on curl itself, which people can do themselves already in a number of different
ways to suit them.
You mention a few possible improvements, but there seems to be a lack of
clarity of what wcurl is supposed to be. Is it a more simple interface to curl
for certain use cases? Is it a low-resource way to access curl functionality
with a wget interface? Is it a wget replacement rewritten from the ground up
using libcurl to perform transfers?
When I saw the announcement, I thought it was the second case, namely a way for
people used to wget to run curl. It wouldn't add functionality that curl didn't
already have, but it would give access to what it DID have in a familiar way.
I talked about this a bit on IRC, since this is an idea I've had for a long
time that I've never acted on. My idea was that a small script would translate
options for features that curl already supports and just call curl to perform
the transfer in the end. So --bind-address would be translated to --interface,
--no-clobber would translate to --skip-existing, --https-only would translate
to "--proto -all,https", etc. And the options (like -r) that curl doesn't
support would cause an error.
As it is, the current wcurl doesn't do that and can't do that because its only
current option (-o) is already defined by both wget and curl in completely
different and incompatible ways. So, given that, I don't really see what the
path forward is for further wcurl improvements, unless it just becomes a third
new utility for performing network transfers.
I personally think that second case hits a sweet spot in that it adds
significant functionality (a new user interface for curl) that many people are
familiar with in only a few KB of space without significant portability
concerns (although it sounds like the getopt issue needs to be solved). That
would be a Busybox-style approach to wget functionality. Actually, Busybox
already supports a "wget" applet, but reimplemented the Busybox way and only
supporting 14 options. A curl version could support many, many more wget
options and would probably take even less space, if we assume that curl is
already available.
The third case (wget reimplemented) would be better as a separate project since
its added functionality strays away from what curl is trying to be.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-07-04