Jabber, est un ensemble de protocoles standards ouvert de l'IETF de messagerie instantanée et de présence. Et parmi toutes les choses innovantes et intéressantes que propose XMPP, nous avons par exemple les ressources et les priorités. Ces deux petites choses permettent de se connecter au même compte simultanément et de sélectionner quel est le logiciel qui recevra les messages (gardez ceci en tête pour la suite du billet). Aussi, en ce moment, parmi les principaux clients de messagerie instantanée basés sur Jabber, on assiste à une véritable régression : on passe de la simplicité d'un logiciel de conversation à l'usine à gaz du logiciel qui veut tout implémenter. Voici donc mon point de vue concernant cette manie qu'ont ces projets principaux de vouloir à tout prix intégrer toutes les fonctionnalités offertes par Jabber/XMPP.

Premièrement, soyons logiques : que faire avec un client Jabber ? Gérer ses contacts, sa présence et discuter avec ses contacts et dans des salons de discussion. Le reste n'est qu'artifice. Seulement voilà, il suffit de voir Gajim (le client que j'utilise) qui, dans sa version de développement, est atteint d'une véritable folie d'intégration. Notamment avec PEP, qui permet l'échange d'informations passionnantes et vitales telles que la musique en écoute, l'humeur ou l'occupation de quelqu'un. Si vous voulez plus d'informations sur cette extension du protocole XMPP, il y a le billet d'Omega résumant tout ça.

Et là, même problème : les clients Jabber (ou tout du moins leurs développeurs) veulent que tout passe par eux. Beurk. Je disais au tout début du billet, dans un succin rappel de ce qu'est Jabber, qu'il existe la possibilité de se connecter simultanément au même compte, ce n'est pas si anodin que ça. Et pour démontrer que la philosophie selon laquelle tout-doit-passer-par-le-client est une mauvaise idée, je vais prendre l'exemple de la musique.

Si Bob écoute du gros-hip-hop-de-r3b3lZ sur son logiciel de lecture de musique et qu'il veut frimer auprès de ses contacts par le simple fait de montrer ce qu'il écoute, que se passe-t-il ?

  • Le lecteur de musique doit implémenter une méthode d'envoi des données propre au client de messagerie qu'il utilise à condition que ce dernier implémente le nécessaire de son côté : si Bob décide de changer de client ou de lecteur de musique, peut-être bien que le support ne sera plus existant
  • Le lecteur de musique ne va implémenter une méthode que pour les clients de messagerie les plus connus et les plus populaires, laissant de côté les autres
  • Bob est obligé d'avoir un client de messagerie instantanée ouvert et connecté
  • Le client de messagerie instantanée de Bob gagne le Trophée International du plus beau score à htop \o/
Pour illustrer mon propos, à condition que vous parliez Python, jetez un coup d'œil à ces fichiers
  1. premièrement, dans le code de decibel-audio-player (non-hébergé sur le net où bien j'ai mal cherché), il y a un fichier src/modules/IMStatus.py qui contient le nécessaire pour contacter les clients de messagerie principaux)
  2. deuxièmement, un autre exemple où le problème a été pris carrément dans l'autre sens (c'est le client de messagerie instantanée qui attend les événements envoyés par le lecteur de musique). Mais les inconvénients restent les mêmes : seuls les logiciels de lecture audio principaux (ou tout du moins, ceux connus des développeurs) sont implémentés : music_track_listener.py (dans Gajim).
Et bien entendu, en attaquant le problème d'un point de vue logique et cohérent, ces désagréments n'existeraient plus. Le lecteur de musique de Bob pourrait très bien se connecter au compte Jabber de Bob dès le lancement et envoyer les notifications d'écoute au fur et à mesure de son utilisation. Parce que comme il est dit au début du billet, on parle de clients de messagerie instantanée utilisant Jabber. Jusqu'à nouvel ordre, un logiciel me permettant de discuter n'a pas à surveiller la musique que j'écoute. Ce n'est pas sa tâche.
D'autant que, comme il est rappelé sur cette page, il est relativement simple de travailler sur une intégration Jabber/PEP. Malheureusement, aucun lecteur de musique connu ne l'implémente. Alors, certes, on peut penser que ce n'est pas non plus le rôle du lecteur de musique d'aller se balader sur le net pour avertir les gens de ce qu'il fait en ce moment. Mais cet argument ne tient pas vraiment la route : presque tous les lecteurs de musique implémentent maintenant des choses comme la soumission des écoutes à Last.fm (le genre de service pas très utile mais ultra-populaire, m'étant moi-même fait prendre au jeu).

D'ailleurs, pour mon projet Bluemindo, j'ai développé un plugin permettant justement d'envoyer des notifications via PEP (jolie capture d'écran) alors qu'Omega a développé un robot pour MPD. Cette façon de faire semble plus logique puisque c'est le lecteur de musique qui lit la musique, donc, si quelqu'un doit avertir, c'est lui. Le client de messagerie instantanée n'a rien à voir là dedans.

Du coup, une seule chose à retenir de ce billet :

  • aux développeurs de clients de messagerie instantanée : allégez ces usines à gaz de ces fonctionnalités qui ne leurs sont pas propres
  • aux développeurs de lecteurs de musique : ajoutez à vos options les notifications PEP (et arrêtez de pourrir les messages de statut des gens)
Que des XEP variées continuent de naître, mais qu'on ne voit pas arriver dans ces clients de messagerie instantanée le dessin, le jeu ou l'écriture de textes à plusieurs. Qu'un logiciel fasse le travail qui lui revient sans faire celui d'un autre (et moins bien, en plus).

Seul bémol à tout ça, dans mon exemple, un problème va se déplacer et les logiciels de lecture de musique vont finir par devenir des usines à gaz (quoique, la majorité des lecteurs de musique sont déjà des grosses usines à gaz inutilisables, non ?). D'où un certain intérêt pour des projets à suivre comme lastfmsubmitd et pourquoi pas un équivalent xmppsubmitd ?

Aidez Bob à frimer de la meilleure façon possible.