curl / Mailing Lists / curl-library / Single Mail
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

From: Olivier Delhomme via curl-library <>
Date: Wed, 29 Sep 2021 21:32:22 +0200

Hi Daniel,

Thanks for your answer.

On Wed, Sep 29, 2021 at 12:07:33AM +0200, Daniel Stenberg wrote:
> 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.

And this stability is a real plus as it may avoid a lot of
changes and adaptations in softwares using libcurl.

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

I didn't remember that…

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

It is an issue with open source projects not only maintaining them
a longer time.

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

I was speaking of maintaining already released versions with security
patches. May be choosing whether to integrate a fix or upgrade to a
newer version is a task that belongs to the one that distributes
libcurl. Finally there is no need to distinguish between security patch
upgrades and feature upgrade because the latter can be done

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

I absolutely agree with that.



Continuous data protection for GNU/Linux (GPL v3)
Current version v0.0.12.
 . Download source code :
 . Contribute to project:

Received on 2021-09-29