Hello everyone, Since I'm seeing some requests for curl to start shipping wcurl, I figure I should write what I believe are the downsides of the current implementation.
Everytime I need to make a decision, I try to think really hard about the downsides, then after I think I covered it all I can be sure about the the best decision. I won't discuss the upsides, as you're aware of them and again I think the downsides matter the most for decisions like this. As I mentioned in https://samueloph.dev/blog/announcing-wcurl-a-curl-wrapper-to-download-files/, the ideal solution for this would probably be something that interfaces directly with libcurl, giving better control over what's possible and reusing the build tools that curl has (tests etc...). All of the downsides I will list here are a result of wcurl being a simple shell script. 1) Setting custom arguments is not great (-o/--opts): It requires that the user passes them through -o or --opts= and all arguments need to be passed a single thing. This is unlikely to change with the current implementation because it requires a lot of logic for argument parsing and it starts to become easy to break. An ideal solution would just forward every argument straight to curl, without this extra level of parsing (unless you want to implement different options, maybe "namespaced"). Granted, one could say it's fine since most people won't need any custom arguments, otherwise they can go with curl directly. 2) It currently doesn't work on non-linux environments: This one should be fixed quite soon, but I should list it here because it's a current issue. Supporting the long form argument "--opts" is what's breaking non-linux support right now. I don't know exactly what we'll do about it but one option is to only allow the short form "-o" (alternative being a more complex argument parsing). 3) No bash/fish-completion: Not feasible to implement unless the curl build tools are used. 4) Lack of flexibility for implementing more complex options: We can't, for example, use both --remote-name and --continue-at, or make the progress bar work with parallel downloads (can't also have the progress bar together with the speed information). Again, to make it clear, I don't want to discourage you from shipping upstream, if anything this is a way of encouraging. Maybe wcurl doesn't have to be that complete for now, it could be shipped as a script and then eventually rewritten. The only concerning one is number 1, and that's because it's something that's more difficult to revert. If wcurl is shipped upstream while allowing -o/--opts, it will be hard to remove that if a rewrite happens (and curl has its own -o already). For now, no single stable linux has shipped wcurl, and won't happen anytime in the next 2/3 months at the very least, we can have breaking changes on wcurl (for example, if you would like to change the way -o/--opts works. I also want to be very careful about not making it harder for curl to ship a different implementation of wcurl, so please always feel free to let me know about any concerns. As a side note, I will surely be happy if wcurl is taken by upstream as it is, so no concerns over the act itself. Thank you -- Samuel Henrique <samueloph> -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
