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.
Thoughts about upstreaming wcurl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Samuel Henrique via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 4 Jul 2024 19:15:02 +0100
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
Date: Thu, 4 Jul 2024 19:15:02 +0100
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.htmlReceived on 2024-07-04