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