Tu oublie l'entête XML, la balise stream et tout ses namespaces. Et je ne parle pas du protocole de transport si on communique pas directement sur les ports XMPP (HTTP entre autre...)
Non je n'ai pas oublié la négociation de base, c'est juste que ça n'est pas pertinent ici. C'est une fois au début ça, ça n'est pas ce qui est envoyé à chaque message, et c'est présent dans n'importe quel protocole.
XMPP est indépendant du protocole de transport, tu peux l'utiliser sur TCP (ce qui est le cas courant décrit dans les RFC), ou HTTP, ou autre. Si tu choisis d'utiliser autre chose que TCP, tu as probablement des bonnes raisons (utilisation dans un navigateur, vouloir passer un NAT, ou que sais-je), et dans ce cas tu as les avantages/inconvénients du transport en dessous, mais ça n'a rien à voir avec XMPP lui même, donc je ne vois pas trop le rapport.
Et donc non, ce n'est pas léger. Le XML n'est pas léger. Si c'était le cas, il n'y aurait pas eu d'autres formats créés pour les échanges de données, comme YAML ou JSON.
J'ai pas non plus dit que XMPP était le format de sérialisation le plus léger du monde, j'ai dit que XMPP était relativement léger et certainement pas lourd comme tu l'indiques. Tu t'avances un peu sur les raisons de créations d'autre formats de sérialisation, JSON a l'avantage (pour le web) d'être un sous ensemble du Javascript, YAML est pratique pour la lecture, je ne suis pas sûr que la raison principal de leur création est la supposée lourdeur de XML. Si c'était l'objectif principal, on se tournerait vers des formats binaires.
IRC n'est peut être pas le bon exemple pour comparer. Alors prenons ICQ par exemple. Pour envoyer ton message d'exemple, avec un ICQ ça prend 32 octets + longueur du message (6) soit 38 octets. Avec XMPP, il faut 54 octets rien que pour ta balise message, sans compter l'en tête XML, la balise stream, les éventuels caractères blanc entre les balises etc.
Mais j'ai l'impression que tu penses que l'en-tête XML et la balise de stream sont envoyés à chaque message, ça n'est absolument pas le cas ! Et accessoirement le flux peut être compressé, donc ce qui passe effectivement dans les câbles est nettement plus petit que le message XML que le développeur peut voir/générer.
Elle définit que le schema XML du protocol, donc que celui-ci repose sur XML et pas sur autre chose à priori (à moins qu'il y ait une autre XEP qui propose une alternative à XML ?)
non, elle définit le fonctionnement du processus de standardisation, ce sont les RFCs qui indiquent que ça utilise du XML, et ça peut effectivement être changé par des XEPs comme celle que j'ai indiqué dans mon précédent message.
[^] # Re: Léger ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 5.
Non je n'ai pas oublié la négociation de base, c'est juste que ça n'est pas pertinent ici. C'est une fois au début ça, ça n'est pas ce qui est envoyé à chaque message, et c'est présent dans n'importe quel protocole.
XMPP est indépendant du protocole de transport, tu peux l'utiliser sur TCP (ce qui est le cas courant décrit dans les RFC), ou HTTP, ou autre. Si tu choisis d'utiliser autre chose que TCP, tu as probablement des bonnes raisons (utilisation dans un navigateur, vouloir passer un NAT, ou que sais-je), et dans ce cas tu as les avantages/inconvénients du transport en dessous, mais ça n'a rien à voir avec XMPP lui même, donc je ne vois pas trop le rapport.
J'ai pas non plus dit que XMPP était le format de sérialisation le plus léger du monde, j'ai dit que XMPP était relativement léger et certainement pas lourd comme tu l'indiques. Tu t'avances un peu sur les raisons de créations d'autre formats de sérialisation, JSON a l'avantage (pour le web) d'être un sous ensemble du Javascript, YAML est pratique pour la lecture, je ne suis pas sûr que la raison principal de leur création est la supposée lourdeur de XML. Si c'était l'objectif principal, on se tournerait vers des formats binaires.
Mais j'ai l'impression que tu penses que l'en-tête XML et la balise de stream sont envoyés à chaque message, ça n'est absolument pas le cas ! Et accessoirement le flux peut être compressé, donc ce qui passe effectivement dans les câbles est nettement plus petit que le message XML que le développeur peut voir/générer.
non, elle définit le fonctionnement du processus de standardisation, ce sont les RFCs qui indiquent que ça utilise du XML, et ça peut effectivement être changé par des XEPs comme celle que j'ai indiqué dans mon précédent message.