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.html
