La page sur psyc.eu semble oublier divers choses, et ne donne pas de récapitulatif des problémes
1) manque de reliabilité. contrairement à l'expérience de l'auteur, j'ai jamais vu de message perdu. J'ai souvent vu mon serveur tenté de renvoyer les messages, sous la forme de message d'erreur multiple.
2) idle connection. Probléme d'implementation, mais il n'y a pas de lien vers les rapports de bugs si ils existent.
3) roster Asynchronicity, pas de méthodes exacts sur comment reproduire le probléme. Et une fois encore, c'est un probléme d'implémentation.
4) Scalability. Il y a une xep (xep 0133 ) sur le multicast pour ça (et l'intégration en cours dans ejabberd ). Et je suis désolé, c'est pas des pourcentages qu'il faut donner pour savoir si ça monte en charge, mais la bande passante utilisé. Au boulot, on a coupé le cache dns de windows, on a eu une augmentation de 200% du trafic dns interne, clairement vu sur les graphes par un passage de 1k de bande passante à 3k. 200%, ça fait beaucoup, 2k de trafic réseau, ça fait rien en réseau local. Avant de dire que jabber ne scale pas, il faut déja savoir si le probléme vient de la bande passante, de la mémoire, ou d'autres choses.
5) Probléme pour savoir si un noeud est up ou pas. Il y a la xep-0199, pour le ping, qui est relativement trivial à implementer.
6) XML, soit l 'auteur n'aime pas xml. Parce qu'il peut pas transferer des données binaires, parce qu'on peut pas décider de réduire les données à un seul octet ( et tant pis pour l'extensibilité ), parce qu'on peut pas étendre xml facilement, bref, des tas de raisons aussi valides que les commentaires à la fin de la page
7) Xmpp vs Xml, il a pas du lire la rfc qui dit que le protocol sert à streamer des éléments en xml, pas que le flux soit forcement un document valide. Néanmoins, l'auteur ayant la bonne idée de coller des morceaux en allemand, j'ai du sans doute mal comprendre.
8) Having to Guess the Meaning of a Packet, oui, ça s'appelle un protocole extensible. Psyc, permettant la même chose ( à savoir spécialiser les messages ), aura sans doute le même probléme, si un jour il est étendu.
9) MUC the "Multi-User Conference", on passeras sur l'attaque à la con, tout les wikis ne sont pas la pour qu'on pose des questions en toute anarchie, et concentrons nous sur le fait que oui, la forme actuelle des mucs ne permet pas d'avoir 700 personnes dans une chatroom. Soit, et vu l'état actuel, en quoi ça pose probléme, car j'ai jamais vu un salon avec plus de 25 personnes ? Des gens sont conscients du probléme, travaillent dessus ( http://www.xmpp.org/extensions/inbox/distributedmuc.html ), et je pense que ça sera réglé en temps et en heure. Il est connu qu'avec des ressources limités, on peut pas tout faire en même temps.
Le reste est du même tonneau. Bien qu'ayant certaines critiques valides, je pense que la plupart sont noyés sous un style provocant, et sous des manques des initiatives récentes.
Pour en revenir à freenode, irc et les mucs, il faut bien voir que la structure du réseau jabber en forme de federation est bien plus scalable à mon sens que les approches en réseau séparé d'irc, mais peut être que mon intuition est fausse.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 4.
1) manque de reliabilité. contrairement à l'expérience de l'auteur, j'ai jamais vu de message perdu. J'ai souvent vu mon serveur tenté de renvoyer les messages, sous la forme de message d'erreur multiple.
2) idle connection. Probléme d'implementation, mais il n'y a pas de lien vers les rapports de bugs si ils existent.
3) roster Asynchronicity, pas de méthodes exacts sur comment reproduire le probléme. Et une fois encore, c'est un probléme d'implémentation.
4) Scalability. Il y a une xep (xep 0133 ) sur le multicast pour ça (et l'intégration en cours dans ejabberd ). Et je suis désolé, c'est pas des pourcentages qu'il faut donner pour savoir si ça monte en charge, mais la bande passante utilisé. Au boulot, on a coupé le cache dns de windows, on a eu une augmentation de 200% du trafic dns interne, clairement vu sur les graphes par un passage de 1k de bande passante à 3k. 200%, ça fait beaucoup, 2k de trafic réseau, ça fait rien en réseau local. Avant de dire que jabber ne scale pas, il faut déja savoir si le probléme vient de la bande passante, de la mémoire, ou d'autres choses.
5) Probléme pour savoir si un noeud est up ou pas. Il y a la xep-0199, pour le ping, qui est relativement trivial à implementer.
6) XML, soit l 'auteur n'aime pas xml. Parce qu'il peut pas transferer des données binaires, parce qu'on peut pas décider de réduire les données à un seul octet ( et tant pis pour l'extensibilité ), parce qu'on peut pas étendre xml facilement, bref, des tas de raisons aussi valides que les commentaires à la fin de la page
7) Xmpp vs Xml, il a pas du lire la rfc qui dit que le protocol sert à streamer des éléments en xml, pas que le flux soit forcement un document valide. Néanmoins, l'auteur ayant la bonne idée de coller des morceaux en allemand, j'ai du sans doute mal comprendre.
8) Having to Guess the Meaning of a Packet, oui, ça s'appelle un protocole extensible. Psyc, permettant la même chose ( à savoir spécialiser les messages ), aura sans doute le même probléme, si un jour il est étendu.
9) MUC the "Multi-User Conference", on passeras sur l'attaque à la con, tout les wikis ne sont pas la pour qu'on pose des questions en toute anarchie, et concentrons nous sur le fait que oui, la forme actuelle des mucs ne permet pas d'avoir 700 personnes dans une chatroom. Soit, et vu l'état actuel, en quoi ça pose probléme, car j'ai jamais vu un salon avec plus de 25 personnes ? Des gens sont conscients du probléme, travaillent dessus ( http://www.xmpp.org/extensions/inbox/distributedmuc.html ), et je pense que ça sera réglé en temps et en heure. Il est connu qu'avec des ressources limités, on peut pas tout faire en même temps.
Le reste est du même tonneau. Bien qu'ayant certaines critiques valides, je pense que la plupart sont noyés sous un style provocant, et sous des manques des initiatives récentes.
Pour en revenir à freenode, irc et les mucs, il faut bien voir que la structure du réseau jabber en forme de federation est bien plus scalable à mon sens que les approches en réseau séparé d'irc, mais peut être que mon intuition est fausse.