Re: Above and beyond 32 protocols

From: Olivier Delhomme via curl-library <curl-library_at_lists.haxx.se>
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
transparently.

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

Regards,

Olivier.

-- 
Continuous data protection for GNU/Linux (GPL v3)
Current version v0.0.12.
 . Download source code : http://cdpfgl.delhomme.org/download/releases/
 . Contribute to project: https://github.com/dupgit/sauvegarde

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Received on 2021-09-29