Pour répondre globalement à ce post je dirais que ces grosses boites ont souhaités se passer de XMPP pour plusieurs choses :
- Les standards c'est chiants, et comme tu le dis si bien, si tu contrôle la chaine, pourquoi s'emmerder à vouloir être compatible avec les autres ? Quand tu es un grand acteur (comme Google) et que tu es imposant sur un marché (le mail avec Gmail), mais pas assez pour dominer, tu te plie aux standards et tu reste compatible. Se passer de XMPP casse des choses mais pas tant que ça en fait vu la "faible" utilisation de celui-ci atour de ces acteurs.
- XMPP est utilisé à 10% de sa capacité, voir moins. À combien de personnes, même dans la communauté du libre, je dois expliquer que non XMPP n'est pas uniquement pour le chat mais peut faire bien plus? On a plus de 300 extensions maintenant mais certaines d'entre elles sont a peine implémentés (Pubsub, sortit en 2008, jamais implémenté en totalité sur un serveur, et coté client...)
- Elles ont pas "compris" l'intérêt de XMPP, parcequ'elles se sont cantonnés à faire du chat par dessus, comme 80% des autres projets. Mais je pense que ce soucis vient aussi de la XSF qui doit activement communiquer sur les possibilités offertes par XMPP.
Avant de critiquer les multinationales parcequ'elles font des chôses dans leurs intérêts, regardons nous, libristes. On a attendu que Mozilla arrive pour faire du Web l'un des domaines les plus innovants de l'informatique moderne. Coté réseaux sociaux on a des dizaines de projets (StatusNet, Pump.io, Diaspora, Matrix...) qui sont certes très intéressants mais qui ne règlent pas le "problème" général. Quand Mozilla a bossé sur Firefox, ils ne voulaient pas créer UN Web pour eux, ils voulaient améliorer LE Web dans son ensemble.
Donc oui XMPP est critiquable, oui le XML sépabo, oui c'est chiant d'écrire une XEP pour dire comment gérer la sauvegarde d'un message sur un serveur mais c'est nécessaire.
Quand Google a voulu se mettre à XMPP ils ont tenté la fédération et ont proposé un client simple (Google Talk) et qui était dispo sur pas mal de plateformes à l'époque. Ils ont également travaillé à la "standardisation" (à leur manière certes) et au développement de la visio sur le protocole, ce qui nous a apporté Jingle. As t'on vu une révolution depuis ? Peut-on facilement faire de la visio sur nos machines de libristes ? Non. La norme est là pourtant. Et pourtant Pidgin n'a pas bougé, Gajim a une implémentation plus que buggé, Empathy pareil, les seuls qui se bougent sont Jitsi.
Résultat des courses, c'est grâce au Web qu'on a de la visio pas trop pourrit avec WebRTC, grâce à qui ? Mozilla et Google (principalement).
Donc avant d'aller voir pourquoi ça marche pas chez les autres améliorons nos clients, Pidgin ne semble pas bouger depuis plusieurs années, pourtant c'est pas compliqué il suffit juste d'implémenter la norme. Pour les nouveaux projets (comme Empathy) ils se cantonne au strict minimum (liste de contact, vcard et présence).
Je bosse sur le protocole XMPP depuis plus de 5 ans déjà et mon principal problème n'est pas d'écrire des normes ni d'essayer de l'implémenter dans mon client (Movim). Mon problème c'est de voir que je suis le seul (avec Jappix, SàT et quelques autres clients) à vouloir aller de l'avant, et c'est usant, très usant. J'ai créé un petit tableau récapitulatif du support de la normes sur les principaux clients ici https://pod.movim.eu/?q=about#caps_widget , il y a encore de très grosses lacunes chez pas mal de clients.
Donc avant de vouloir réinventer un énième protocole "social" essayez d'améliorer l'existant. XMPP offre, selon moi, les ingrédients pour créer une petite révolutions dans le domaine des échanges sociaux sur le Internet.
Pour vous donner quelques idées :
- Sur le papier on peut associer WebRTC et Jingle, Jappix l'a fait et semble être le seul à le faire assez bien. WebRTC colle au niveau protocolaire avec les solutions de visio "classiques" (hors du Web) pourquoi ne travaillons nous pas à rendre compatible Pidgin, Gajim... avec WebRTC ? Les normes sont là, il "suffit" juste de les implémenter.
- Sur XMPP on peut sauvegarder les bookmarks de nos clients (salons de discussions...), la norme existe... et pourtant. Pidgin sauvegarde ses bookmarks en local, Gajim fait à sa façon... bref même un truc aussi simple n'est pas fini. Du coup Goffi, moi et quelques autres motivés allons réécrire et simplifier la norme (http://xmpp.org/extensions/xep-0048.html) pour, espérons le, faciliter l'implémentation dans ces clients.
- Les XEP Vcard4 et Avatar permettent de "pusher" les informations entre les contacts, qu'est ce qui est encore majoritairement implémentés ? vcard-temp, XEP historique (http://xmpp.org/extensions/xep-0054.html) sortie en 2008 et qui fonctionne en pulling (il faut requêter une à une les vcard de vos contacts). J'ai implémenté Vcard4 tout seul en une après-midi sans grande difficulté, le nombre de projets qui ont fait de même se comptent sur les doigts d'une main. Petit détail, il n'y a rien à faire coté serveur (enfin il faut qu'ils supportent PEP, ce qui est déjà fait pour la majorité d'entre eux).
Donc pour résumer, la solution on l'a sous nos yeux, il faut juste l'implémenter et rendre compatible nos projets existants.
[^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?
Posté par edhelas (site web personnel) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 6. Dernière modification le 31 mai 2015 à 00:49.
Pour répondre globalement à ce post je dirais que ces grosses boites ont souhaités se passer de XMPP pour plusieurs choses :
- Les standards c'est chiants, et comme tu le dis si bien, si tu contrôle la chaine, pourquoi s'emmerder à vouloir être compatible avec les autres ? Quand tu es un grand acteur (comme Google) et que tu es imposant sur un marché (le mail avec Gmail), mais pas assez pour dominer, tu te plie aux standards et tu reste compatible. Se passer de XMPP casse des choses mais pas tant que ça en fait vu la "faible" utilisation de celui-ci atour de ces acteurs.
- XMPP est utilisé à 10% de sa capacité, voir moins. À combien de personnes, même dans la communauté du libre, je dois expliquer que non XMPP n'est pas uniquement pour le chat mais peut faire bien plus? On a plus de 300 extensions maintenant mais certaines d'entre elles sont a peine implémentés (Pubsub, sortit en 2008, jamais implémenté en totalité sur un serveur, et coté client...)
- Elles ont pas "compris" l'intérêt de XMPP, parcequ'elles se sont cantonnés à faire du chat par dessus, comme 80% des autres projets. Mais je pense que ce soucis vient aussi de la XSF qui doit activement communiquer sur les possibilités offertes par XMPP.
Avant de critiquer les multinationales parcequ'elles font des chôses dans leurs intérêts, regardons nous, libristes. On a attendu que Mozilla arrive pour faire du Web l'un des domaines les plus innovants de l'informatique moderne. Coté réseaux sociaux on a des dizaines de projets (StatusNet, Pump.io, Diaspora, Matrix...) qui sont certes très intéressants mais qui ne règlent pas le "problème" général. Quand Mozilla a bossé sur Firefox, ils ne voulaient pas créer UN Web pour eux, ils voulaient améliorer LE Web dans son ensemble.
Donc oui XMPP est critiquable, oui le XML sépabo, oui c'est chiant d'écrire une XEP pour dire comment gérer la sauvegarde d'un message sur un serveur mais c'est nécessaire.
Quand Google a voulu se mettre à XMPP ils ont tenté la fédération et ont proposé un client simple (Google Talk) et qui était dispo sur pas mal de plateformes à l'époque. Ils ont également travaillé à la "standardisation" (à leur manière certes) et au développement de la visio sur le protocole, ce qui nous a apporté Jingle. As t'on vu une révolution depuis ? Peut-on facilement faire de la visio sur nos machines de libristes ? Non. La norme est là pourtant. Et pourtant Pidgin n'a pas bougé, Gajim a une implémentation plus que buggé, Empathy pareil, les seuls qui se bougent sont Jitsi.
Résultat des courses, c'est grâce au Web qu'on a de la visio pas trop pourrit avec WebRTC, grâce à qui ? Mozilla et Google (principalement).
Donc avant d'aller voir pourquoi ça marche pas chez les autres améliorons nos clients, Pidgin ne semble pas bouger depuis plusieurs années, pourtant c'est pas compliqué il suffit juste d'implémenter la norme. Pour les nouveaux projets (comme Empathy) ils se cantonne au strict minimum (liste de contact, vcard et présence).
Je bosse sur le protocole XMPP depuis plus de 5 ans déjà et mon principal problème n'est pas d'écrire des normes ni d'essayer de l'implémenter dans mon client (Movim). Mon problème c'est de voir que je suis le seul (avec Jappix, SàT et quelques autres clients) à vouloir aller de l'avant, et c'est usant, très usant. J'ai créé un petit tableau récapitulatif du support de la normes sur les principaux clients ici https://pod.movim.eu/?q=about#caps_widget , il y a encore de très grosses lacunes chez pas mal de clients.
Donc avant de vouloir réinventer un énième protocole "social" essayez d'améliorer l'existant. XMPP offre, selon moi, les ingrédients pour créer une petite révolutions dans le domaine des échanges sociaux sur le Internet.
Pour vous donner quelques idées :
- Sur le papier on peut associer WebRTC et Jingle, Jappix l'a fait et semble être le seul à le faire assez bien. WebRTC colle au niveau protocolaire avec les solutions de visio "classiques" (hors du Web) pourquoi ne travaillons nous pas à rendre compatible Pidgin, Gajim... avec WebRTC ? Les normes sont là, il "suffit" juste de les implémenter.
- Sur XMPP on peut sauvegarder les bookmarks de nos clients (salons de discussions...), la norme existe... et pourtant. Pidgin sauvegarde ses bookmarks en local, Gajim fait à sa façon... bref même un truc aussi simple n'est pas fini. Du coup Goffi, moi et quelques autres motivés allons réécrire et simplifier la norme (http://xmpp.org/extensions/xep-0048.html) pour, espérons le, faciliter l'implémentation dans ces clients.
- Les XEP Vcard4 et Avatar permettent de "pusher" les informations entre les contacts, qu'est ce qui est encore majoritairement implémentés ? vcard-temp, XEP historique (http://xmpp.org/extensions/xep-0054.html) sortie en 2008 et qui fonctionne en pulling (il faut requêter une à une les vcard de vos contacts). J'ai implémenté Vcard4 tout seul en une après-midi sans grande difficulté, le nombre de projets qui ont fait de même se comptent sur les doigts d'une main. Petit détail, il n'y a rien à faire coté serveur (enfin il faut qu'ils supportent PEP, ce qui est déjà fait pour la majorité d'entre eux).
Donc pour résumer, la solution on l'a sous nos yeux, il faut juste l'implémenter et rendre compatible nos projets existants.
edhelas