Perso, s'il y a bien un truc a changer pour moi, c'est XML.
Non pas parce que c'est verbeux (c'est verbeux, mais c'est pas le problème) mais précisément pour ce que tu penses être un non-problème:
Pas de support du binaire
Pourquoi ? XMPP est un protocole de routage, pourquoi devrait-il dicter quoi que ce soit sur le format du contenu ? (Je pense aussi a XHTML-IM, qui va dans le même sens: en fonction du contenu que tu as a envoyer, tu dois le formater correctement...)
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.
Pas de framing
Encore une fois, je considère XMPP comme un protocole de routage. Du coup, les éléments sur la route n'ont pas besoin de savoir ce qu'ils routent... et pourtant, ils doivent parser tout le stanza pour récupérer les éléments qui les intéressent. Même si ça les concerne a peine; je pense par exemple aux stanza dans la XEP de microblogging, qui concernent pas le serveur mais plutôt le service de microblogging lui-même, et pourtant ils sont assez énormes. Tout ce qui les intéresse, c'est le "to" du message pour savoir dans quel tuyau envoyer le stanza. Et ça peut aller plus loin, pour reprendre l'exemple du microblogging, on pourrait imaginer pour un domaine suffisamment gros que les items sont envoyés sur un serveur différent en fonction du node associé; ça, c'est pas faisable simplement avec XML, mais avec du framing propre c'est envisageable.
C'est même pas du vrai XML
Bon la c'est plus pour le troll qu'autre chose, parce que je connais pas suffisamment, mais c'est pas moi qui le dit, c'est les gens de Psyc et cette lib.
Du coup
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, parce que faut pas se mentir, un protocole ouvert ne se répand que s'il est facilement implementable. Mais je garderai la structure générale des messages et de leur traitement qu'on a aujourd'hui, pour le peu que je connais ça marche plutôt bien
Du coup JSON n'est pas une solution, mais je pense par exemple a bencode (moyen) ou otnetstring (mieux) avec une spécification supplémentaire pour garder la compatibilité avec le XML existant (du genre, un element == un dict, les attributs sont des valeurs dont les clés sont par exemple "@xmlns" ou "@to", les éléments a l’intérieur sont accessibles via leur nom, potentiellement avec leur xmlns, et si c'est pas du dict on y accede via "#in")
[^] # Re: on refait le protocole
Posté par rakoo (site web personnel) . En réponse au journal Retour de Berlin. Évalué à 4.
Perso, s'il y a bien un truc a changer pour moi, c'est XML.
Non pas parce que c'est verbeux (c'est verbeux, mais c'est pas le problème) mais précisément pour ce que tu penses être un non-problème:
Pas de support du binaire
Pourquoi ? XMPP est un protocole de routage, pourquoi devrait-il dicter quoi que ce soit sur le format du contenu ? (Je pense aussi a XHTML-IM, qui va dans le même sens: en fonction du contenu que tu as a envoyer, tu dois le formater correctement...)
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.
Pas de framing
Encore une fois, je considère XMPP comme un protocole de routage. Du coup, les éléments sur la route n'ont pas besoin de savoir ce qu'ils routent... et pourtant, ils doivent parser tout le stanza pour récupérer les éléments qui les intéressent. Même si ça les concerne a peine; je pense par exemple aux stanza dans la XEP de microblogging, qui concernent pas le serveur mais plutôt le service de microblogging lui-même, et pourtant ils sont assez énormes. Tout ce qui les intéresse, c'est le "to" du message pour savoir dans quel tuyau envoyer le stanza. Et ça peut aller plus loin, pour reprendre l'exemple du microblogging, on pourrait imaginer pour un domaine suffisamment gros que les items sont envoyés sur un serveur différent en fonction du node associé; ça, c'est pas faisable simplement avec XML, mais avec du framing propre c'est envisageable.
C'est même pas du vrai XML
Bon la c'est plus pour le troll qu'autre chose, parce que je connais pas suffisamment, mais c'est pas moi qui le dit, c'est les gens de Psyc et cette lib.
Du coup
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, parce que faut pas se mentir, un protocole ouvert ne se répand que s'il est facilement implementable. Mais je garderai la structure générale des messages et de leur traitement qu'on a aujourd'hui, pour le peu que je connais ça marche plutôt bien
Du coup JSON n'est pas une solution, mais je pense par exemple a bencode (moyen) ou otnetstring (mieux) avec une spécification supplémentaire pour garder la compatibilité avec le XML existant (du genre, un element == un dict, les attributs sont des valeurs dont les clés sont par exemple "@xmlns" ou "@to", les éléments a l’intérieur sont accessibles via leur nom, potentiellement avec leur xmlns, et si c'est pas du dict on y accede via "#in")