URL:     https://linuxfr.org/news/24-ans-de-libcurl
Title:   24 ans de libcurl
Authors: Benoît Sibaud
        Ysabeau  đź§¶ 🧦 et bobble bubble
Date:    2024-08-07T08:42:07+02:00
License: CC By-SA
Tags:    curl et bibliothèque
Score:   4


_Curl_ est un outil en ligne de commande destiné à récupérer le contenu d’une ressource accessible par un réseau informatique et gérant de nombreux protocoles.



_Curl_ est un outil essentiel pour de nombreux usages, pris en charge par une gamme très large de systèmes d’exploitation, d’architectures matérielles, de l’objet connecté à l’[embarqué spatial](https://daniel.haxx.se/blog/2023/02/07/closing-the-nasa-loop/) en passant par l’informatique classique ou les consoles de jeux. Il évolue rapidement et fréquemment, voir par exemple [l’arrivée prochaine de HTTP3 pour curl dans Debian unstable (avec le backend gnutls)](https://linuxfr.org/users/trim/liens/arrivee-prochaine-de-http3-pour-curl-dans-debian-unstable-avec-le-backend-gnutls). Son domaine d’utilisation pourrait encore s’étendre avec [l’apparition de wcurl dans Debian et bientôt dans le monde entier ?](https://linuxfr.org/users/ploum/journaux/apparition-de-wcurl-dans-debian-et-bientot-dans-le-monde-entier)

Il y a 24 ans, une division du code entre une interface ligne de commande et une bibliothèque a été faite.

----

[libcurl is 24 years old (6 août 2024)](https://daniel.haxx.se/blog/2024/08/06/libcurl-is-24-years-old/)
[curl 8.9.1 (31 juillet 2024)](https://daniel.haxx.se/blog/2024/07/31/curl-8-9-1/)
[Curl](https://curl.se/)

----

(Cette dépêche est principalement basée sur l’annonce anglophone par Daniel Stenberg, auteur principal de _curl_ et _libcurl_ ; dépêche rédigée sur un téléphone embarquant curl 7.80, pas vraiment la dernière version…).


La première version de _libcurl_, baptisée 7.1, date du 7 août 2000. La version de _curl_ précédente, la 6.5.2, pas encore séparée entre une interface ligne de commande et une bibliothèque. Il s’agit de l’écart le plus long entre deux versions de _curl_. La création de la bibliothèque a été très largement réalisée par Daniel Stenberg seul.



Il décrit son choix de division ainsi : _c'était juste une intuition et une conjecture. Je ne savais pas. Je n’avais pas fait de recherches sur cela ou autre chose. Je me suis juste lancé en me disant qu’on verrait plus tard si j’avais raison ou tort._



Le nom de la bibliothèque a été choisi faute d’une meilleure idée. L’API a été définie comme étant bas niveau (on peut toujours ajouter une API de plus haut niveau par-dessus), en observant ioctl(), fcntl() et les fonctions du genre. Le code est en C, langage de prédilection de l’auteur principal.



L’API a bien vieilli : 17 fonctions encore présentes proviennent de la 7.1 ; elle est passée de 17 000 lignes à 171 000 ; elle a survécu aux _révolutions_ HTTP/2 (transferts multiples multiplexés) et HTTP/3 (passer de TCP à UDP).



L’usage a aussi bien progressé depuis l’entrée dans PHP 4.0.2 comme premier _binding_ (ici rendre utilisable en langage PHP), moins d’un mois après la publication de la bibliothèque.



En 2002 a été ajoutée une API _multi_ pour gérer des transferts parallèles concurrents de façon illimitée dans un même _thread_.



Puis en 2006 vient en surplus le _multi_action_ avec des mécanismes orientés événements, avec une boucle événementielle (comme _epoll_).



Les premiers changements douloureux sur l’interface binaire (ABI) ont entraîné une volonté de stabilité, de ne jamais casser volontairement cette interface, et ce depuis 2006.



_libcurl_ possède des _bindings_ vers au moins 65 langages de programmation, fonctionne sur au moins 103 systèmes d’exploitation et 28 architectures de processeur, est prĂ©sent dans les bibliothèques standard de langages de programmation (Python, Java, Rust  ou .Net). Son ancien concurrent principal _libwww_ n’est plus dĂ©veloppĂ©. Bref 18 ans de stabilitĂ© d’API et d’ABI.



L’utilisation de _libcurl_ continue de croître (de plus en plus d’objets connectés notamment). Et _curl_ de manière générale supporte rapidement les nouveaux protocoles et leurs évolutions. À noter que l’auteur principal ne mentionne pas dans ses projections ce qui me semble le plus gros risque pour Curl/libcurl, la difficulté d’avoir une personne prête à lui succéder ~~si~~ quand cela s’avérera nécessaire.