Buy commercial curl support from WolfSSL. 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
himself.
Re: Above and beyond 32 protocols
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 29 Sep 2021 00:07:33 +0200 (CEST)
On Tue, 28 Sep 2021, Olivier Delhomme wrote:
> I'd love to know what are your thoughts about GreenIt / low tech and the
> paths that we may need to walk through to reduce our environmental footprint
> [1] such as:
>
> * limit or (better) reduce features in programs,
One of our best and most appreciated features in libcurl is its ABI stability.
We can't have ABI stability and reduce features at the same time.
But for those that build their own libcurls, I think we should continue to
offer build-time opt-in switches to disable features and protocols from the
build. That's at least one way of reducing features in particular builds.
> * maintain released versions for a much more longer time (such
> as 7 years [2]).
I would love to maintain released versions a long time and I'm ready to do
this if someone pays for it. Asking an open source project to take on even
more work for free "for the good of society" is just not going to work. We
still need food on the table.
But also, "maintain released versions" is a very soft requirement. What does
it mean? If you talk about maintaining, you still mean shipping updates that
users can upgrade to and we are already working hard to allow users to upgrade
without roadbumps. In that aspect we already "maintain" releases for much
longer than seven years.
> Is it conceivable to make choices of which protocols may stay
> or not in curl and keep only 32 of them ?
That would mean to not add support for more protocols. Looking at the history
of curl and the Internet the past twenty years up until now, and thinking
about what could possible happen in the coming twenty years, it seems like a
very hard limit to say that we can't follow what happens and what users will
want. I don't see how that would be good for curl, for its users or for the
ecosystem at large.
Date: Wed, 29 Sep 2021 00:07:33 +0200 (CEST)
On Tue, 28 Sep 2021, Olivier Delhomme wrote:
> I'd love to know what are your thoughts about GreenIt / low tech and the
> paths that we may need to walk through to reduce our environmental footprint
> [1] such as:
>
> * limit or (better) reduce features in programs,
One of our best and most appreciated features in libcurl is its ABI stability.
We can't have ABI stability and reduce features at the same time.
But for those that build their own libcurls, I think we should continue to
offer build-time opt-in switches to disable features and protocols from the
build. That's at least one way of reducing features in particular builds.
> * maintain released versions for a much more longer time (such
> as 7 years [2]).
I would love to maintain released versions a long time and I'm ready to do
this if someone pays for it. Asking an open source project to take on even
more work for free "for the good of society" is just not going to work. We
still need food on the table.
But also, "maintain released versions" is a very soft requirement. What does
it mean? If you talk about maintaining, you still mean shipping updates that
users can upgrade to and we are already working hard to allow users to upgrade
without roadbumps. In that aspect we already "maintain" releases for much
longer than seven years.
> Is it conceivable to make choices of which protocols may stay
> or not in curl and keep only 32 of them ?
That would mean to not add support for more protocols. Looking at the history
of curl and the Internet the past twenty years up until now, and thinking
about what could possible happen in the coming twenty years, it seems like a
very hard limit to say that we can't follow what happens and what users will
want. I don't see how that would be good for curl, for its users or for the
ecosystem at large.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-09-29