Il est probable que si tous les développeurs de clients XMPP concentraient leur effort sur un client au lieu de toute une tripotée, ils arriveraient à y faire tenir plus de fonctionnalités et à se concentrer plus sur ce que l'utilisateur veux.
ça n'est pas si simple, les clients ont des architectures et des contraintes différentes. La méthode la plus commune aujourd'hui pour faire un client qui tourne partout serait de faire du web et d'utiliser Electron pour porter ça ailleurs que dans le navigateur. Ça marche, mais c'est lourd et ça n'est pas du natif, ce qui peut poser tout un tas de problèmes. C'est souvent ce que font les applications de messagerie (ou autre) les plus connues, mais y'a du monde derrière pour arrondir les angles (et on revient au problème du temps/des ressources disponibles). Il faut aussi noter que beaucoup de clients ont été commencés bien avant qu'Electron existe.
Conversations c'est du Java + API Android, difficilement portable. Gajim (probablement le plus complet), c'est du Python + GTK, là c'est déjà beaucoup plus portable, mais on va avoir des soucis sur Android, iOS, Web.
D'un autre côté, Movim utilise justement Electron, et fait du Material Design avec voix et tout, donc a priori tout ce qui est à la mode... sauf le chiffrement de bout en bout avec OMEMO, parce que c'est difficile à faire proprement avec cette architecture.
Et dans mon cas particulier, un projet comme SàT a une architecture différente qui fait une grande partie de sa spécificité, difficile de partir d'un client pensé pour le bureau (ce qui était le cas de la majorité des clients à l'époque où ça a été commencé) pour faire ça.
Après il y a le cas de ceux qui veulent faire un client spécifique à une plateforme, et qui utilisent ce qu'ils connaissent, c'est le cas de 2 clients récents (Dino qui utilise Vala, et Kaidan qui utilise Qt).
Et il est probable que ça leur plaise plus de coder un client en partant de zéro que de contribuer à un client existant.
c'est extrêmement rare qu'un client parte de zéro. Bien souvent une bibliothèque est utilisée et complétée quand nécessaire.
[^] # Re: qu'est-ce qui a planté ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Lire un vieux journal, ça fout le cafard. Évalué à 7.
ça n'est pas si simple, les clients ont des architectures et des contraintes différentes. La méthode la plus commune aujourd'hui pour faire un client qui tourne partout serait de faire du web et d'utiliser Electron pour porter ça ailleurs que dans le navigateur. Ça marche, mais c'est lourd et ça n'est pas du natif, ce qui peut poser tout un tas de problèmes. C'est souvent ce que font les applications de messagerie (ou autre) les plus connues, mais y'a du monde derrière pour arrondir les angles (et on revient au problème du temps/des ressources disponibles). Il faut aussi noter que beaucoup de clients ont été commencés bien avant qu'Electron existe.
Conversations c'est du Java + API Android, difficilement portable. Gajim (probablement le plus complet), c'est du Python + GTK, là c'est déjà beaucoup plus portable, mais on va avoir des soucis sur Android, iOS, Web.
D'un autre côté, Movim utilise justement Electron, et fait du Material Design avec voix et tout, donc a priori tout ce qui est à la mode... sauf le chiffrement de bout en bout avec OMEMO, parce que c'est difficile à faire proprement avec cette architecture.
Et dans mon cas particulier, un projet comme SàT a une architecture différente qui fait une grande partie de sa spécificité, difficile de partir d'un client pensé pour le bureau (ce qui était le cas de la majorité des clients à l'époque où ça a été commencé) pour faire ça.
Après il y a le cas de ceux qui veulent faire un client spécifique à une plateforme, et qui utilisent ce qu'ils connaissent, c'est le cas de 2 clients récents (Dino qui utilise Vala, et Kaidan qui utilise Qt).
c'est extrêmement rare qu'un client parte de zéro. Bien souvent une bibliothèque est utilisée et complétée quand nécessaire.