Non du tout, XMPP c'est la couche applicative, au même niveau que HTTP. C'est au dessus d'un autre protocole qui s'occupera du transport (en général TCP), qui lui-même est au dessus d'un autre protocole qui lui s'occupe du routage (IP).
Sur ce point je vois pas pourquoi il faudrait ouvrir une 2e connexion en parallèle alors qu'on en a déjà une. Ouvrir une 2e connexion c'est intéressant si t'as un flux long terme en parallèle, comme de la VoIP. Mais avoir du binaire dans la connexion déjà ouverte, ça peut être utilisé par exemple pour un petit transfert (genre image de chaton dans le salon de discussion) ou pour signer/chiffrer un message.
Franchement même des "petits transferts", ben si t'en as plein, ben c'est plus si petit. Si le mec inonde le chat d'images de chatons, je peux te dire: heureusement que c'est sur un flux parallèle! Tu te mettrais à devoir attendre que les chatons soient tous chargés pour continuer à suivre la discussion (qui elle prend vraiment peu de place donc est rapide à charger, mais serait tout de même bloquer). D'ailleurs cela pourrait être une bonne attaque pour bloquer une discussion sur un salon de discussion.
Je note que même les protocoles dinosaures chargent les images sur une connexion parallèle. Quand tu télécharges une page html au dessus de HTTP, les images ne sont pas incluses dans la page html. Elle sont chargées en parallèle, ce qui permet ainsi aux gens par exemple d'interdire le chargement et affichage des images sur les pages. De même qu'en XMPP on pourrait faire la même chose. Avec des images directement dans le flux, on ne peut même plus refuser les images et une connexion entrante peut nous forcer à accepter toute sorte de fichier binaire de X Go, et ainsi bloquer la connexion. Donc non, vraiment non. Ce serait un énorme retour en arrière dans les protocoles du net, et dire que c'est un problème de XMPP est une aberration.
Encore une fois, je considère XMPP comme un protocole de routage.
Et encore une fois, ça l'est pas du tout. XMPP, y a exactement autant de routage que dans le protocole SMTP pour envoyer des emails (c'est à dire aucun, ou alors vraiment minime si tu considères le très haut niveau "j'envoie à tel domaine"). Le routage est fait sur des couches bien inférieures (à base de DNS, IP, etc.). Franchement déjà je devrais m'arrêter là sur ton argumentation. Ça fait déjà deux fois que tu la bases sur un truc totalement faux.
et pourtant, ils doivent parser tout le stanza pour récupérer les éléments qui les intéressent.
Je sais pas ce que t'appelles parser tout le stanza. Parce qu'effectivement, le serveur va vérifier la syntaxe parce qu'il faut bien savoir où le stanza termine (de même qu'il doit rompre la connexion en cas de XML mal formé et ne va sûrement pas transférer un flux qu'il sait non valide). Mais ça s'arrête là. Si le stanza est bien formé, le serveur va se contenter de regarder le destinataire et va transférer le stanza. Il va pas faire de traitement particulier.
C'est même pas du vrai XML
Wé tes liens, c'est effectivement du troll de compète. Ils disent des conneries bien grosses et n'ont apparemment pas compris ce qu'est XMPP. Alors déjà, XMPP c'est du XML. Seulement oui, c'est un sous-set de XML (mais sous-set, c'est toujours du XML. Tu mets un flux XMPP dans n'importe quel parseur XML, ce sera du XML valide). Des choses comme les commentaires ou les Processing Instructions ne sont en effet pas acceptés, déjà pour simplifier, mais ensuite parce que ça n'a aucun sens dans un flux automatisé. Tu vas mettre des commentaires dans ton fichier XML écrit à la main pour noter des choses pour toi, mais un flux automatisé, c'est juste idiot. De même qu'un générateur de code n'insérera pas de commentaire dans son code généré. Aussi il faut bien comprendre qu'on parle d'un flux XML. C'est pas un document XML qu'on met sur son disque dur. Le concept change énormément de choses et le mec mélange tout (d'ailleurs il base un point de son argumentation sur un mail paumé de 2004 pour un point qui n'est même plus vrai depuis la RFC 6120! Faut se mettre à jour des fois. Je vois dans l'historique du wiki qu'il a pourtant mis à jour la page en 2013, bien après la sortie de la RFC 6120, mais faut croire que ça l'intéresse pas de vérifier ses dires. Ça montre la confiance qu'on peut accorder à son propos. Il a juste envie de casser du sucre sur XMPP et n'importe quel argument, vrai ou faux, est juste bon à prendre).
On se demande vraiment pourquoi ce mec se fait chier à faire une page juste pour dire des inepties pareilles. Et pis ensuite faudrait savoir: on se plaint parce que XMPP est en XML, et on se plaint quand XMPP ne fait pas tout XML, même les fonctionnalités les plus obscures et aussi les plus inutiles dans le cas qui nous intéresse. Alors on est content quand?
S'il y a une chose que je changerais, ce serait remplacer XML par un protocole qui répond a ces deux besoins tout en restant humainement lisible/hackable
Franchement si y a bien quelque chose qu'on ne peut pas reprocher à XML, en tous cas dans son utilisation dans XMPP, c'est d'être "lisible/hackable". XMPP est justement génial pour tester et développer pour ce côté là, car on peut très très facilement tester son implémentation "à la main". T'as un problème avec ton programme, tu te connectes en telnet (ensuite tu automatises un peu, quasi tous les clients ont une console XML pour les tests, de nos jours) et tu tapes tes stanzas au clavier (ou copies-colles), tu lis directement les réponses du serveur, etc. Pas besoin de décodeur binaire, pas besoin d'essayer de déchiffrer une syntaxe obtuse et condensée. Même si bien sûr les stanzas envoyés sont tout serrés, c'est super simple à remettre en forme automatiquement avec des tabulations pour la lecture à plat, etc.
Ensuite oui, dans ce cas, les gens de l'autre côté diront que c'est bien la preuve que c'est trop verbeux. "C'est fait pour la lecture humaine, vous voyez, pas le traitement informatique." Et là je répond: compression. De nos jours, on a des compressions rapides et efficaces, et ça tombe bien, le texte se compresse extrêmement bien! Tout le côté verbeux et répétitif du XML disparaît à la compression. Et ça tombe encore mieux: XMPP prend en charge la compression depuis des années et probablement la totalité des clients et serveurs ont implémenté cela (car c'est tellement simple à implémenter).
Donc au final on a lisible + comprimé. Que demande le peuple?
Mais au final? Tout ça, c'est du gros troll. Les batailles XML/json/autre, c'est comme les langages de programmation. Qu'est-ce qu'on s'en fout?! T'avais qu'à être le premier à faire un tel projet, mais maintenant que c'est là, tu vas tout refaire juste parce que t'aimes pas le format ou le langage utilisé? Si quelqu'un prouve que le design est trop profondément mauvais, et donc limité, et qu'y a plein de trucs trop importants qu'on pourra pas faire avec, pourquoi pas. Mais se braquer parce que c'est XML? Perso un développeur qui me sort ça, je ne vais même pas le prendre au sérieux. On peut avoir des préférences, ça c'est une chose. Mais un projet qui existe et qui fait ce qu'on lui demande et qui peut potentiellement faire plus, on va pas se plaindre des choix des précédents développeurs. On fait avec, on met son amour propre au placard et on améliore le bousin. Ou alors on se barre sans dire mot, mais on va pas faire un caca nerveux à critiquer ceux qui ont mis du cœur à l'ouvrage pour en faire ce qu'il est. D'ailleurs qui n'a jamais fait d'erreur et a fait les meilleurs choix à chaque fois tout au long de sa vie?
Franchement XML, je m'en fous. Je suis ni fan ni ennemi. Json, pareil j'ai déjà bosser avec. Et je bosserai avec ce que tu veux d'autre si je tombe sur un projet qui utilise. À un moment donné, faut arrêter de se regarder le nombril et être constructif plutôt que destructif.
Pour finir: désolé si ça a l'air un peu énervé. Je promets, je le suis pas. C'est juste le type de sujet qui revient souvient, et je sais pas pourquoi, aujourd'hui je me sentais dans une humeur de débat. Mais c'est pas contre toi, ni rien. Mais réellement je suis pas de mauvais poil! :p
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: on refait le protocole
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Retour de Berlin. Évalué à 10.
Non du tout, XMPP c'est la couche applicative, au même niveau que HTTP. C'est au dessus d'un autre protocole qui s'occupera du transport (en général TCP), qui lui-même est au dessus d'un autre protocole qui lui s'occupe du routage (IP).
Franchement même des "petits transferts", ben si t'en as plein, ben c'est plus si petit. Si le mec inonde le chat d'images de chatons, je peux te dire: heureusement que c'est sur un flux parallèle! Tu te mettrais à devoir attendre que les chatons soient tous chargés pour continuer à suivre la discussion (qui elle prend vraiment peu de place donc est rapide à charger, mais serait tout de même bloquer). D'ailleurs cela pourrait être une bonne attaque pour bloquer une discussion sur un salon de discussion.
Je note que même les protocoles dinosaures chargent les images sur une connexion parallèle. Quand tu télécharges une page html au dessus de HTTP, les images ne sont pas incluses dans la page html. Elle sont chargées en parallèle, ce qui permet ainsi aux gens par exemple d'interdire le chargement et affichage des images sur les pages. De même qu'en XMPP on pourrait faire la même chose. Avec des images directement dans le flux, on ne peut même plus refuser les images et une connexion entrante peut nous forcer à accepter toute sorte de fichier binaire de X Go, et ainsi bloquer la connexion. Donc non, vraiment non. Ce serait un énorme retour en arrière dans les protocoles du net, et dire que c'est un problème de XMPP est une aberration.
Et encore une fois, ça l'est pas du tout. XMPP, y a exactement autant de routage que dans le protocole SMTP pour envoyer des emails (c'est à dire aucun, ou alors vraiment minime si tu considères le très haut niveau "j'envoie à tel domaine"). Le routage est fait sur des couches bien inférieures (à base de DNS, IP, etc.). Franchement déjà je devrais m'arrêter là sur ton argumentation. Ça fait déjà deux fois que tu la bases sur un truc totalement faux.
Je sais pas ce que t'appelles parser tout le stanza. Parce qu'effectivement, le serveur va vérifier la syntaxe parce qu'il faut bien savoir où le stanza termine (de même qu'il doit rompre la connexion en cas de XML mal formé et ne va sûrement pas transférer un flux qu'il sait non valide). Mais ça s'arrête là. Si le stanza est bien formé, le serveur va se contenter de regarder le destinataire et va transférer le stanza. Il va pas faire de traitement particulier.
Wé tes liens, c'est effectivement du troll de compète. Ils disent des conneries bien grosses et n'ont apparemment pas compris ce qu'est XMPP. Alors déjà, XMPP c'est du XML. Seulement oui, c'est un sous-set de XML (mais sous-set, c'est toujours du XML. Tu mets un flux XMPP dans n'importe quel parseur XML, ce sera du XML valide). Des choses comme les commentaires ou les Processing Instructions ne sont en effet pas acceptés, déjà pour simplifier, mais ensuite parce que ça n'a aucun sens dans un flux automatisé. Tu vas mettre des commentaires dans ton fichier XML écrit à la main pour noter des choses pour toi, mais un flux automatisé, c'est juste idiot. De même qu'un générateur de code n'insérera pas de commentaire dans son code généré. Aussi il faut bien comprendre qu'on parle d'un flux XML. C'est pas un document XML qu'on met sur son disque dur. Le concept change énormément de choses et le mec mélange tout (d'ailleurs il base un point de son argumentation sur un mail paumé de 2004 pour un point qui n'est même plus vrai depuis la RFC 6120! Faut se mettre à jour des fois. Je vois dans l'historique du wiki qu'il a pourtant mis à jour la page en 2013, bien après la sortie de la RFC 6120, mais faut croire que ça l'intéresse pas de vérifier ses dires. Ça montre la confiance qu'on peut accorder à son propos. Il a juste envie de casser du sucre sur XMPP et n'importe quel argument, vrai ou faux, est juste bon à prendre).
On se demande vraiment pourquoi ce mec se fait chier à faire une page juste pour dire des inepties pareilles. Et pis ensuite faudrait savoir: on se plaint parce que XMPP est en XML, et on se plaint quand XMPP ne fait pas tout XML, même les fonctionnalités les plus obscures et aussi les plus inutiles dans le cas qui nous intéresse. Alors on est content quand?
Franchement si y a bien quelque chose qu'on ne peut pas reprocher à XML, en tous cas dans son utilisation dans XMPP, c'est d'être "lisible/hackable". XMPP est justement génial pour tester et développer pour ce côté là, car on peut très très facilement tester son implémentation "à la main". T'as un problème avec ton programme, tu te connectes en telnet (ensuite tu automatises un peu, quasi tous les clients ont une console XML pour les tests, de nos jours) et tu tapes tes stanzas au clavier (ou copies-colles), tu lis directement les réponses du serveur, etc. Pas besoin de décodeur binaire, pas besoin d'essayer de déchiffrer une syntaxe obtuse et condensée. Même si bien sûr les stanzas envoyés sont tout serrés, c'est super simple à remettre en forme automatiquement avec des tabulations pour la lecture à plat, etc.
Ensuite oui, dans ce cas, les gens de l'autre côté diront que c'est bien la preuve que c'est trop verbeux. "C'est fait pour la lecture humaine, vous voyez, pas le traitement informatique." Et là je répond: compression. De nos jours, on a des compressions rapides et efficaces, et ça tombe bien, le texte se compresse extrêmement bien! Tout le côté verbeux et répétitif du XML disparaît à la compression. Et ça tombe encore mieux: XMPP prend en charge la compression depuis des années et probablement la totalité des clients et serveurs ont implémenté cela (car c'est tellement simple à implémenter).
Donc au final on a lisible + comprimé. Que demande le peuple?
Mais au final? Tout ça, c'est du gros troll. Les batailles XML/json/autre, c'est comme les langages de programmation. Qu'est-ce qu'on s'en fout?! T'avais qu'à être le premier à faire un tel projet, mais maintenant que c'est là, tu vas tout refaire juste parce que t'aimes pas le format ou le langage utilisé? Si quelqu'un prouve que le design est trop profondément mauvais, et donc limité, et qu'y a plein de trucs trop importants qu'on pourra pas faire avec, pourquoi pas. Mais se braquer parce que c'est XML? Perso un développeur qui me sort ça, je ne vais même pas le prendre au sérieux. On peut avoir des préférences, ça c'est une chose. Mais un projet qui existe et qui fait ce qu'on lui demande et qui peut potentiellement faire plus, on va pas se plaindre des choix des précédents développeurs. On fait avec, on met son amour propre au placard et on améliore le bousin. Ou alors on se barre sans dire mot, mais on va pas faire un caca nerveux à critiquer ceux qui ont mis du cœur à l'ouvrage pour en faire ce qu'il est. D'ailleurs qui n'a jamais fait d'erreur et a fait les meilleurs choix à chaque fois tout au long de sa vie?
Franchement XML, je m'en fous. Je suis ni fan ni ennemi. Json, pareil j'ai déjà bosser avec. Et je bosserai avec ce que tu veux d'autre si je tombe sur un projet qui utilise. À un moment donné, faut arrêter de se regarder le nombril et être constructif plutôt que destructif.
Pour finir: désolé si ça a l'air un peu énervé. Je promets, je le suis pas. C'est juste le type de sujet qui revient souvient, et je sais pas pourquoi, aujourd'hui je me sentais dans une humeur de débat. Mais c'est pas contre toi, ni rien. Mais réellement je suis pas de mauvais poil! :p
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]