Heureusement que tu précises que t'es pas énervé, parce qu'on pourrait croire le contraire :)
Débattons, débattons !
J'aimerais juste rappeler le point de départ de la discussion, qui est la question intéressante posée par devnewton:
si vous deviez refaire un protocole depuis 0 aujourd'hui, est-ce que vous aboutiriez à un XMPP like ou à complètement autre chose?
À laquelle je réponds "XMPP c'est top, ça juste marche dans les cas où on l'utilise le plus, c'est extensible, c'est ouvert, c'est implémenté de milles et une manières et ça a pas l'air de s’essouffler de ce coté là". Bref, c'est bien, il faut aller dans ce sens et améliorer l'existant plutôt que réinventer la roue. Je suis d'accord avec toi. Si on devait recommencer de 0, on pourrait garder une grosse grosse majorité de ce qu'on a déjà.
Mais (et ça n'est que mon avis), ça n'est pas parfait, et si je devais recommencer de 0 je changerais XML par autre chose. Encore une fois, expérience de pensée !
Maintenant, quelques précisions:
Sur le routage
Je persiste et signe, XMPP est un protocole de routage, clairement pas au sens de "routage de paquets IP", mais bien "routage de fragment XML". La différence est qu'une table de routage, c'est à dire l'ensemble des routeurs qu'un routeur connaît et à qui il est capable de parler, c'est l'ensemble des domaines qui ont un serveur.
Cas simple: je veux envoyer un message à edward@snowden.com; le seul qui sait comment faire c'est snowden.com. Je ne connais pas snowden.com, par contre mon serveur le connaît; j'envoie mon stanza à mon serveur qui transmet.
Cas MUC/Pubsub: c'est du multicast tout ce qu'il y a de plus connu. Ma ressource -> mon serveur -> le serveur qui héberge le service de pubsub -> le noeud pubsub, et inversement pour la diffusion (Note que cette fois ce qui est routé c'est pas un stanza entier, c'est le(s) item(s))
Cas un peu plus compliqué: je veux parler à quelqu'un sur IRC. Ma ressource -> mon serveur -> le serveur qui héberge la passerelle -> la passerelle (possiblement en tant que composant) -> IRC
Je vois XMPP comme étant capable de beaucoup plus que juste amener les stanza d'un client à un autre: par exemple si un domaine héberge un "serveur" XMPP sur un cluster de serveurs, ça serait vraiment bien d'utiliser XMPP de bout en bout. Ça permettrait par exemple de construire "facilement" des clusters en prenant n'importe quelle implémentation qui respecte les standards pour se faire son n-ième SecretWhatSnapLine, et ainsi faire avancer le protocole (soit en participant au réseau, soit en améliorant les outils existants).
Ça va vachement plus loin que SMTP, qui s'arrête au To, là on a potentiellement plusieurs niveaux de routage qui permettent un adressage vraiment fin.
Sur le binaire
J'ai l'impression que tu fais le raccourci "binaire => gros machin qui bouche le tuyau".
C'est très certainement vrai si tu utilises la manière naïve, qui est de tout mettre dans un gros paquet, ce qui est à mon sens sacrément stupide. Dans ce cas-là tu segmentes ton binaire, tu l'envoies morceau par morceau avec la possibilité pour les messages non-binaires de passer. Mais c'est vrai, ça veut aussi dire qu'un participant à une MUC peut envoyer des méga-gifs de chatons qui vont juste embêter tout le monde. Au fond je me disais juste "qui peut le plus peut le moins": si le protocole pouvait utiliser du binaire, il pourrait faire passer n'importe quoi par dessus, y compris du XML structuré comme ce qu'on a aujourd'hui, mais aussi du HTML sans avoir à l'échapper ou un message chiffré/signé sans avoir à le base64.
Sur le parsing
Parser, ça veut dire passer la suite d'octets reçus de la socket dans la moulinette pour en extraire une structure qui a du sens (de manière à poser quelques pointeurs qui permettent un accès rapide aux différents éléments). Sauf que si c'est un serveur, le "sens" qui l'intéresse, il s'arrête au to; le sens de ce qu'il y a en dessous c'est surtout pour le niveau suivant, par exemple le module de pubsub, qui potentiellement peut être sur un autre serveur (routage, encore). Dans ce cas là on aura 2 "analyses" complètes du message...
Plus généralement
Encore une fois, je parle de ce qu'il y aurait à changer si on repartait de 0, mais c'est clairement du chipotage, et ça n'enlève en rien les qualités de XMPP. Je crois que la seule bonne conclusion qu'on peut avoir c'est si on repartait de 0, on arriverait largement à la même chose.
[^] # Re: on refait le protocole
Posté par rakoo (site web personnel) . En réponse au journal Retour de Berlin. Évalué à 4.
Heureusement que tu précises que t'es pas énervé, parce qu'on pourrait croire le contraire :)
Débattons, débattons !
J'aimerais juste rappeler le point de départ de la discussion, qui est la question intéressante posée par devnewton:
À laquelle je réponds "XMPP c'est top, ça juste marche dans les cas où on l'utilise le plus, c'est extensible, c'est ouvert, c'est implémenté de milles et une manières et ça a pas l'air de s’essouffler de ce coté là". Bref, c'est bien, il faut aller dans ce sens et améliorer l'existant plutôt que réinventer la roue. Je suis d'accord avec toi. Si on devait recommencer de 0, on pourrait garder une grosse grosse majorité de ce qu'on a déjà.
Mais (et ça n'est que mon avis), ça n'est pas parfait, et si je devais recommencer de 0 je changerais XML par autre chose. Encore une fois, expérience de pensée !
Maintenant, quelques précisions:
Sur le routage
Je persiste et signe, XMPP est un protocole de routage, clairement pas au sens de "routage de paquets IP", mais bien "routage de fragment XML". La différence est qu'une table de routage, c'est à dire l'ensemble des routeurs qu'un routeur connaît et à qui il est capable de parler, c'est l'ensemble des domaines qui ont un serveur.
Cas simple: je veux envoyer un message à edward@snowden.com; le seul qui sait comment faire c'est snowden.com. Je ne connais pas snowden.com, par contre mon serveur le connaît; j'envoie mon stanza à mon serveur qui transmet.
Cas MUC/Pubsub: c'est du multicast tout ce qu'il y a de plus connu. Ma ressource -> mon serveur -> le serveur qui héberge le service de pubsub -> le noeud pubsub, et inversement pour la diffusion (Note que cette fois ce qui est routé c'est pas un stanza entier, c'est le(s) item(s))
Cas un peu plus compliqué: je veux parler à quelqu'un sur IRC. Ma ressource -> mon serveur -> le serveur qui héberge la passerelle -> la passerelle (possiblement en tant que composant) -> IRC
Je vois XMPP comme étant capable de beaucoup plus que juste amener les stanza d'un client à un autre: par exemple si un domaine héberge un "serveur" XMPP sur un cluster de serveurs, ça serait vraiment bien d'utiliser XMPP de bout en bout. Ça permettrait par exemple de construire "facilement" des clusters en prenant n'importe quelle implémentation qui respecte les standards pour se faire son n-ième SecretWhatSnapLine, et ainsi faire avancer le protocole (soit en participant au réseau, soit en améliorant les outils existants).
Ça va vachement plus loin que SMTP, qui s'arrête au To, là on a potentiellement plusieurs niveaux de routage qui permettent un adressage vraiment fin.
Sur le binaire
J'ai l'impression que tu fais le raccourci "binaire => gros machin qui bouche le tuyau".
C'est très certainement vrai si tu utilises la manière naïve, qui est de tout mettre dans un gros paquet, ce qui est à mon sens sacrément stupide. Dans ce cas-là tu segmentes ton binaire, tu l'envoies morceau par morceau avec la possibilité pour les messages non-binaires de passer. Mais c'est vrai, ça veut aussi dire qu'un participant à une MUC peut envoyer des méga-gifs de chatons qui vont juste embêter tout le monde. Au fond je me disais juste "qui peut le plus peut le moins": si le protocole pouvait utiliser du binaire, il pourrait faire passer n'importe quoi par dessus, y compris du XML structuré comme ce qu'on a aujourd'hui, mais aussi du HTML sans avoir à l'échapper ou un message chiffré/signé sans avoir à le base64.
Sur le parsing
Parser, ça veut dire passer la suite d'octets reçus de la socket dans la moulinette pour en extraire une structure qui a du sens (de manière à poser quelques pointeurs qui permettent un accès rapide aux différents éléments). Sauf que si c'est un serveur, le "sens" qui l'intéresse, il s'arrête au to; le sens de ce qu'il y a en dessous c'est surtout pour le niveau suivant, par exemple le module de pubsub, qui potentiellement peut être sur un autre serveur (routage, encore). Dans ce cas là on aura 2 "analyses" complètes du message...
Plus généralement
Encore une fois, je parle de ce qu'il y aurait à changer si on repartait de 0, mais c'est clairement du chipotage, et ça n'enlève en rien les qualités de XMPP. Je crois que la seule bonne conclusion qu'on peut avoir c'est si on repartait de 0, on arriverait largement à la même chose.