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: Randall via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 4 Jul 2024 15:08:16 -0400
On Thursday, July 4, 2024 2:51 PM, Dan Fandrich wrote:
>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.
I am considering porting wcurl to NonStop. We already have curl, wget, and
wget2 running. We would need portable getopt().
Date: Thu, 4 Jul 2024 15:08:16 -0400
On Thursday, July 4, 2024 2:51 PM, Dan Fandrich wrote:
>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.
I am considering porting wcurl to NonStop. We already have curl, wget, and
wget2 running. We would need portable getopt().
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-07-04