Session Restore Finally Exists On Wayland
La vidéo retrace le long et paradoxal parcours du protocole XDG de gestion de session pour Wayland, un outil essentiel pour la restauration des applications après un crash, dont l'adoption a été unanimement approuvée mais étrangement retardée pendant des années.
SYNTHÈSE STRUCTURÉE
Un protocole longtemps attendu
L’intervenant annonce avec enthousiasme la fusion récente du protocole XDG de gestion de session dans Wayland. Ce protocole, initialement proposé en 2018, permet de négocier la restauration de l’état des fenêtres d’une application après un crash du compositeur ou pour économiser des ressources. Il comble ainsi un manque crucial : « This feels like one of those major oversights with Wayland that should have been there from the very start. »
Un besoin pratique et clair
L’objectif est concret : permettre aux applications de retrouver leur état précédent (position, taille, etc.) après un incident, une fonctionnalité basée sur un protocole existant d’Enlightenment. L’intervenant souligne que « if your compositor crashes, you can then reopen the compositor and the applications are back like they were », bien que cela nécessite aussi une coopération des applications elles-mêmes.
Un développement sans conflit majeur
Contrairement à de nombreux autres protocoles Wayland souvent sources de vifs débats, celui-ci a bénéficié d’un consensus quasi-total. L’intervenant note avec surprise : « For the most part, and I know this is rare in Wayland, basically smooth sailing. Like, no blockers ». Les discussions ont principalement porté sur des détails d’implémentation et de formulation, sans remise en cause fondamentale.
Une longue période de latence
Malgré l’accord général, le projet est entré dans une longue phase de stagnation. Après des échanges initiaux, « nothing happened for another two months », puis pendant des mois, l’activité sur le fil principal fut quasi-nulle. L’intervenant explique cela par le fait que les développeurs étaient probablement « distracted with other projects and other protocols that were a lot more mentally intensive ».
L’implication cruciale des grands projets
L’élan décisif est venu lorsque les grands projets de bureau et de toolkits (KDE/Plasma/Qt, GNOME/GTK) se sont impliqués, car ce protocole était un « major blocker » pour une transition complète vers Wayland. Un intérêt est également venu de projets majeurs comme Chromium, qui attendait ce protocole « for implementing workspace restoration ».
L’absurdité du retard final
Le point le plus frappant du récit est que, même avec des implémentations stables et testées en production (dans GNOME 47/48 et KDE), personne n’avait officiellement « ACK » (approuvé) le protocole. L’intervenant s’en amuse : « GNOME was shipping an experimental draft version of the protocol in GNOME 47… And nobody was like, Hey, guys, I think the protocol’s a good idea. » Le protocole était utilisé mais pas formellement validé.
Une fusion enfin obtenue
L’approbation officielle (ACK) de KDE puis de GNOME est finalement intervenue, suivie de la fusion du protocole par Vlad Zahorodnii. L’intervenant résume l’ironie de la situation : « It was a mess because everybody agreed to merge the protocol… It just took way longer than it ever should ». Le retard n’était pas dû à des désaccords, mais à une inertie bureaucratique.
CONCEPTS CLÉS
- Protocole XDG de gestion de session : Un protocole Wayland permettant la sauvegarde et la restauration de l’état des fenêtres des applications (session restoration).
- Compositeur (Compositor) : Logiciel (comme KWin ou Mutter) qui gère l’affichage des fenêtres et des interfaces sous Wayland.
- ACK (Acknowledgment) : Dans le processus de développement de Wayland, une approbation formelle d’un acteur majeur (comme GNOME ou KDE) nécessaire pour fusionner un nouveau protocole.
- OOM Killer (Out-Of-Memory Killer) : Un mécanisme du noyau Linux qui termine des processus pour libérer de la mémoire lorsque le système est à court.
CONCLUSION
Le message principal est que le développement de Wayland peut être freiné non seulement par des conflits techniques, mais aussi par une simple inertie administrative, même lorsque tout le monde est d’accord sur le fond. 🐌 Ce récit illustre les défis de la gouvernance dans les grands projets open source, où une fonctionnalité essentielle et unanimement désirée peut mettre près de huit ans à être officiellement intégrée, non pas à cause de la technique, mais à cause de l’organisation. Cela compte car cela montre que la collaboration et la coordination, au-delà du code, sont des facteurs tout aussi critiques pour l’évolution des plateformes logicielles.