On est d'accord, il y a eu un problème de calendrier. Et oui je te l'accorde, XMPP a mis du temps, beaucoup de temps, à se réveiller et enfin intégrer des fonctionnalités "modernes" de messagerie (partage de fichier, synchronisation des messages entre clients, gestion de l'historique, édition des messages publiés...).
Là où il faut faire attention, et c'est un soucis de rôle qui revient couramment, c'est que "XMPP" n'a pas comme vocation de proposer une solution clé-en-main avec services et clients aux internautes. XMPP est un protocole, au même niveau que SMTP/IMAP/POP ou HTTP le sont pour l'email et le Web. La XSF offre juste une solution de messagerie fédéré.
D'ailleurs c'est une question qui revient assez souvent au sein de la XSF (dont je suis moi même membre). La XSF doit elle pousser ou mettre en avant certains clients ou solutions implémentant XMPP au détriment des autres? Jusqu'ici la réponse a été de jouer la carte de la neutralité et de se cantonner à simplement "faire le job de standardisation".
Mais pour revenir à ta remarque le problème de XMPP a bien été un problème temporel. Aujourd'hui on ne se pose plus la question de savoir quel protocole utiliser pour l'email et le Web, car très tôt un standard a émergé (surtout pour l'email, pour le "Web" ça a été un peu plus compliqué, on se souvient de la bataille des navigateurs dans les années 90-début 2000). Les protocoles et standards gravitant autour de l'email et du Web ne sont pas parfaites, loin de là, mais ont comme avantage de proposer une vision unifiée forçant même les "géants" à se plier à eux (tu peux envoyer un email d'un compte Outlook à un compte Gmail depuis un iPhone sur un Thunderbird installé sur une distro Linux).
Pour la messagerie instantanée (et même le réseau social, ce que j'essaye de montrer avec Movim), malheureusement ce sont les outils qui sont venus avant les protocoles, si bien qu'aujourd'hui il devient difficile d'expliquer que non le problème ne vient pas d'XMPP en lui même, mais du fait qu'il lui faut se justifier face à des solutions centralisées, complète, faciles et intégrées aux interfaces et appareils des utilisateurs.
La question que je poserais donc serait de savoir pourquoi aujourd'hui nous n'avons pas encore de clients/serveurs/plateformes qui permettent d'offrir des solutions de messageries instantanées "modernes" et étant construit sur LE standard (norme IETF, au même titre que POP/IMAP/SMTP/HTTP... le sont) existant.
Cela est entrain de changer, on commence (enfin) à avoir des clients complets et accessibles (Conversations ou Dino https://github.com/dino/dino, voir même Movim (dont je suis le développeur principal)) et les serveurs rattrapent leurs retard rapidement sur ce qui a été standardisé ces dernières années.
Il y a quelques années (je bosse sur Movim depuis 9 ans maintenant) j'étais très dubitatif quand au fait que XMPP soit réellement un protocole viable pour construire une solution moderne de messagerie instantanée (et de réseautage social dans mon cas) mais en travaillant de consorts avec les autres projets (clients comme serveurs) implémentant XMPP, en ouvrant des bugs et discutant continuellement des implémentations et de l'amélioration du protocole j'ai la forte impression qu'on est entrain de transformer l’essai.
Les discussions au sein de la XSF se sont énormément fluidifiés ces derniers mois, les nouvelles fonctionnalités peuvent être standardisés et intégrés en l'espace de quelques mois (alors qu'il fallait bien souvent des années auparavant). Même si nous avons nos propres points de vues je suis heureux de voir qu'il y a des échanges continuels sur comment "bien faire" avant de simplement implémenter et de voir ensuite. Tout ça permet de proposer des serveurs et clients compatibles à leur sortie et d'avoir systématiquement une documentation de référence pour les futur entrants souhaitant communiquer avec les projets existants.
[^] # Re: Tentative de réponse
Posté par edhelas (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 10. Dernière modification le 29 septembre 2017 à 09:26.
On est d'accord, il y a eu un problème de calendrier. Et oui je te l'accorde, XMPP a mis du temps, beaucoup de temps, à se réveiller et enfin intégrer des fonctionnalités "modernes" de messagerie (partage de fichier, synchronisation des messages entre clients, gestion de l'historique, édition des messages publiés...).
Là où il faut faire attention, et c'est un soucis de rôle qui revient couramment, c'est que "XMPP" n'a pas comme vocation de proposer une solution clé-en-main avec services et clients aux internautes. XMPP est un protocole, au même niveau que SMTP/IMAP/POP ou HTTP le sont pour l'email et le Web. La XSF offre juste une solution de messagerie fédéré.
D'ailleurs c'est une question qui revient assez souvent au sein de la XSF (dont je suis moi même membre). La XSF doit elle pousser ou mettre en avant certains clients ou solutions implémentant XMPP au détriment des autres? Jusqu'ici la réponse a été de jouer la carte de la neutralité et de se cantonner à simplement "faire le job de standardisation".
Mais pour revenir à ta remarque le problème de XMPP a bien été un problème temporel. Aujourd'hui on ne se pose plus la question de savoir quel protocole utiliser pour l'email et le Web, car très tôt un standard a émergé (surtout pour l'email, pour le "Web" ça a été un peu plus compliqué, on se souvient de la bataille des navigateurs dans les années 90-début 2000). Les protocoles et standards gravitant autour de l'email et du Web ne sont pas parfaites, loin de là, mais ont comme avantage de proposer une vision unifiée forçant même les "géants" à se plier à eux (tu peux envoyer un email d'un compte Outlook à un compte Gmail depuis un iPhone sur un Thunderbird installé sur une distro Linux).
Pour la messagerie instantanée (et même le réseau social, ce que j'essaye de montrer avec Movim), malheureusement ce sont les outils qui sont venus avant les protocoles, si bien qu'aujourd'hui il devient difficile d'expliquer que non le problème ne vient pas d'XMPP en lui même, mais du fait qu'il lui faut se justifier face à des solutions centralisées, complète, faciles et intégrées aux interfaces et appareils des utilisateurs.
La question que je poserais donc serait de savoir pourquoi aujourd'hui nous n'avons pas encore de clients/serveurs/plateformes qui permettent d'offrir des solutions de messageries instantanées "modernes" et étant construit sur LE standard (norme IETF, au même titre que POP/IMAP/SMTP/HTTP... le sont) existant.
Cela est entrain de changer, on commence (enfin) à avoir des clients complets et accessibles (Conversations ou Dino https://github.com/dino/dino, voir même Movim (dont je suis le développeur principal)) et les serveurs rattrapent leurs retard rapidement sur ce qui a été standardisé ces dernières années.
Il y a quelques années (je bosse sur Movim depuis 9 ans maintenant) j'étais très dubitatif quand au fait que XMPP soit réellement un protocole viable pour construire une solution moderne de messagerie instantanée (et de réseautage social dans mon cas) mais en travaillant de consorts avec les autres projets (clients comme serveurs) implémentant XMPP, en ouvrant des bugs et discutant continuellement des implémentations et de l'amélioration du protocole j'ai la forte impression qu'on est entrain de transformer l’essai.
Les discussions au sein de la XSF se sont énormément fluidifiés ces derniers mois, les nouvelles fonctionnalités peuvent être standardisés et intégrés en l'espace de quelques mois (alors qu'il fallait bien souvent des années auparavant). Même si nous avons nos propres points de vues je suis heureux de voir qu'il y a des échanges continuels sur comment "bien faire" avant de simplement implémenter et de voir ensuite. Tout ça permet de proposer des serveurs et clients compatibles à leur sortie et d'avoir systématiquement une documentation de référence pour les futur entrants souhaitant communiquer avec les projets existants.