Bonjour à tous,
bon je sais qu'on parle beaucoup de XMPP en ce moment, avec les sorties récentes des nouvelles versions de Salut à Toi et Movim, et un journal sur Diapora*, aussi pour ceux qui commencent à saturer, inutile de continuer dans ce journal :).
Je vais raconter un peu l'envers du décors ici, à savoir ce qu'il se passe chez les dévs et autour des standards. Tout est raconté de mon point de vue (je suis développeur sur Salut à Toi), peut-être que les autres personnes présentes voudront compléter ou corriger selon leur ressenti.
Depuis quelques mois, nous avons décidé de nous regrouper sur un salon XMPP pour discuter de « PubSub » (Publish Subscribe, publication/souscription, un protocole qui permet de publier des choses et d'être averti quand quelqu'un publie quelque chose). Quand je dis « nous », je parle principalement de Binary (développeur russe), Edhelas (développeur de Movim), Souliane (développeur de Salut à Toi), et moi. Sur ce salon nous voyons aussi plus ou moins régulièrement des gens comme Simon Tenant (développeur Buddycloud), Neustradamus (qui fait beaucoup de veille et mise en relation aujour de XMPP), Link Mauve (développeur touche à tout, et beaucoup à XMPP), et Vanaryon (développeur de Jappix). Notre but est de pousser un peu pour régler les derniers problèmes gênants pour créer un système de microblogage décentralisé.
Cette réunion a permis la création de 2 XEPs (extensions du protocole XMPP): la XEP-0351 écrite par Binary pour améliorer les notifications, et Priviled Components, que j'ai écrite, qui permet de donner à un composant des droits normalement réservés à un serveur (ça sera bientôt changé pour être pour n'importe quel entité, pas uniquement un composant serveur). La première a été publiée et a donc un numéro officiel, c'est une étape importante, mais cela ne signifie pas que c'est accepté par la XSF (organisme qui gère XMPP, où n'importe qui peut demander à être membre). Le mécanisme de publication et d'acceptation est décrit dans la XEP-0001: ce processus clair est ouvert à la discussion, et montre l'intérêt d'un protocole standard. Par exemple, une XEP ne peut pas devenir finale s'il n'y a pas au moins 2 implémentations dont au moins une libre.
Pour discuter de ces extensions (et plus rarement du cœur de XMPP, à savoir les RFC 6120, 6121 et 6122), une liste de diffusion a été créé, la liste standard (que vous trouverez ainsi que toutes les autres sur cette page: http://xmpp.org/participate/discuss-xmpp/). C'est sur cette liste que Binary a demandé à avoir un « XMPP Summit », c'est à dire une rencontre autour de XMPP, en dehors de l'amérique du Nord. Après quelques discussions, un point relativement central a été choisi, Berlin, où le JSConfEu était organisé, ce qui a permis à ceux qui le voulaient de participer aux 2.
Nous nous sommes donc retrouvé à Berlin la semaine dernière. Afin de pouvoir mieux faire connaissance et pouvoir discuter tranquillement, nous avons décidé de prendre une chambre commune Edhelas (que j'avais déjà vu plusieurs fois), Binary (que je ne connaissais que par Internet), Souliane (ami de longue date) et moi (Vanaryon a failli nous rejoindre mais il a eu un empêchement). Notre choix s'est porté sur une auberge de jeunesse qui respirait l'ambiance communautaire, un peu excentrée. Nous n'avons pas été deçus, l'accueil ainsi que tous ceux qu'on a rencontré étaient très amicaux et détendus.
Mercredi le RDV était donné dans les locaux de Wikimedia (la fondation qui gère entre autres Wikipédia): c'était le grand luxe, de grands bureaux hauts de plafond, des indications claires. La nourriture (pizzas) et les boissons (eau, café, club maté, etc) étaient offertes par &yet, une entreprise qui utilise XMPP. Nous avions tout ce qu'il fallait à disposition: une grand salle de réunion, et une bonne connexion filaire ou wifi.
Une vingtaine de personnes étaient présentes, parmi lesquelles on comptait des développeurs d'OpenFire, de BuddyCloud, d'Ejabberd, de Prosody (l'auteur principal), de Jitsi, ainsi que des employés de Siemens qui nous ont parlé de l'Internet des objets.
Pour permettre aux gens non présents physiquement de participer, une liaison en vidéo conférence à plusieurs a été mise en place via Jitsi et un navigateur (ou le client de bureau chez les autres). Malgré quelque petits problèmes (webcam qui coupait l'image en deux - probablement plus lié à la webcam elle-même qu'à Jitsi -, quelques coupures voire crashs), la liaison a été relativement correcte durant toute la journée, et nous a permis de discuter avec Ralph Meijer, un des auteurs de la XEP-0060 (PubSub), et développeur de longue date autour d'XMPP.
Toute la journée a été rempli de discussions, nous avons commencé par lister les sujets que chacun voulait aborder, puis fait un vote pour choisir l'ordre de discussions. Nous avons ainsi parlé des problèmes de PubSub, de XMPP en entreprise (et de l'utilisation de l'internet des objets), de Jingle, de l'état des « réseau sociaux » (je n'aime pas ce terme !) avec une rapide présentation de Movim et SàT en fin de journée, ainsi que diverses autres choses que j'ai oublié. Je ne vais pas rentrer dans les détails techniques, mais vous pourrez avoir un résumé de ce qu'on a dit sur PubSub ici: http://piratepad.net/ep/pad/view/ro.HADGQ2im4Q3/latest (la mise en page est perdu en lecture seule, je vous conseil de télécharger en HTML avec le lien sur la droite). Le leitmotiv de la journée était « do it ! ».
Cette journée a été très éprouvante pour moi: j'ai été pris tout du long d'un violent mal de tête, ce qui m'a rendu très pénible la compréhension des discussions en anglais, surtout que certains parlaient très vite et avec un accent plus ou moins fort, et la conversation avec Ralph par enceintes interposées n'était pas aisée non plus. Mais nous referons certainement une partie des conversations sur la liste de diffusion standard@.
La fin de la journée, vers 16h, a été un soulagement, et nous nous sommes donnés RDV le soir dans un restaurant. Cette longue pause nous a permis de visiter un peu Berlin et son tristement célèbre mur (mais la ville est très intéressante et semble vraiment agréable, j'espère avoir l'occasion de mieux la découvrir un jour).
Nous étions en comité beaucoup plus réduit au restaurant, à 6, ce qui a permis des discussions plus détendues, et de voir un peu nos différents points de vue.
Le lendemain était la journée du hackathon: nous nous sommes retrouvés dans un hackerspace berlinois, où se croisaient une classique RepRap et un portrait de RMS en Gnou. Cette journée a été beaucoup plus agréable: d'une part mon mal de tête était enfin passé après une nuit épouvantable, et d'autre part l'atmosphére était moins « officielle ». Chacun vaquait à ses occupations, et nous pouvions demander l'aide d'un expert sur tel ou tel projet au besoin, ou s'échanger des astuces. Tout au long de la journée nous avons eu des présentations.
En particulier, Matthew (l'auteur de Prosody) nous a fait une introduction à Lua et Prosody, et nous a montré comment faire un module. Bien que j'avais déjà regardé par ailleurs, c'était très instructif, et Matthew donne un sentiment de compétence très rassurant. C'est un personnage sympathique, décontracté, et facile d'accès. Il nous a expliqué notamment le choix de Lua: un langage très rapide, efficace et qui va à l'essentiel. Le code de Prosody semble clair, et ils ont pour but de ne pas avoir pas de fichier dépassant les 400 lignes environ. Il y a un nombre impressionnant de modules, et la facilité d'en écrire rend Prosody un serveur de choix pour bidouiller. Ajoutons à cela sa visible qualité technique, sa facilité à installer et ses performances, c'est à mon sens un des tous meilleurs serveurs XMPP.
Nous (J'ai ;) ) posé la question qui fâche du fork « Métronome » et de ce qu'il en pensait. Ce fork a été fait afin, entre autres, d'implémenter un PubSub persistant, ce qui n'est pas encore possible dans Prosody. Matthew nous a expliqué que c'est parce qu'ils voulaient éviter une dépendance à une base de données (Prosody gère tout avec des fichiers simples). Il est resté très correct vis à vis de ce projet, et même s'il pense que la méthode d'implémentation n'est pas la bonne, il a dit qu'il est tout de même content que ce projet existe car il est utilisé notamment par Movim et Jappix, et que le libre c'est aussi accepter les forks. Une API est en train d'être créé pour Prosody, afin d'utiliser des bases de données externes sans dépendance dur (si j'ai bien compris), donc on devrait voir arriver tôt ou tard du PubSub persistant. L'autre méthode est d'utiliser un composant externe, méthode que nous avons choisi pour SàT.
Nous avons également eu une présentation de Buddycloud, un projet de microblogage à la Twitter, mais qui se base sur une couche non standard (tout en gardant une passerelle PubSub standard en parallèle si j'ai bien compris là encore). Je pensais le projet moins avancé que cela, et c'était une bonne surprise de le voir tourner. La vision du microblogage est différente de la notre, et Buddycloud semble viser principalement les entreprises (c'est leur modèle économique). Un des développeurs semblait plus ouvert que l'autre à travailler sur une standardisation de leur projet, l'avenir nous dira ce qu'il en est, mais nous espérons en tout cas pouvoir être compatibles à terme.
Une autre présentation intéressante était celle d'une bibliothèque javascript permettant de gérer XMPP, nous avons eu une démonstration en direct: en quelques lignes de code dans la console, il y avait un algorithme qui créait des cercles. Nous étions invités à nous connecter à un site web: chaque connexion créait un cercle que nous pouvions contrôler via des boutons de directions, le tout communiquant par XMPP.
Enfin, nous avons eu le droit à une présentation d'une visions différente de XMPP dans le navigateur: au lieu de tout faire en javascript ou côté serveur, le développeur a créé un plugin (pour Chromium uniquement pour le moment). L'utilisation de ce plugin, permet de demander la permission d'accéder à notre compte XMPP, comme n'importe quel site peut demander la permission d'afficher des notifications ou stocker quelque chose en local. Une fois cette autorisation donnée, il est facile de contrôler le compte en très peu de lignes, sans les tartines javascript normalement nécessaire. J'ai trouvé l'idée très intéressante, mais à mon avis applicable uniquement si c'est un vrai standard disponible partout, et si les permissions sont modulables (c.-à-d. ne pas donner un accès complet systématique au compte XMPP).
À 18h nous avons décidé de quitter les locaux, et de faire un barbecue arrosé de bières allemandes à l'auberge. C'était un bon moyen de se couper un peu du monde informatique après ces 2 jours intenses, et de faire du vrai social avec les voyageurs. Le lendemain nous nous sommes quittés (Binary et Edhelas restant un peu à Berlin), et Souliane et moi sommes rentrés en STOP, pour le plaisir (ne sortez surtout pas à Dresde si un jour ça vous arrive et que vous allez au sud !).
Nous sommes très contents de ce séjour, même si les discussions n'ont pas forcément été si utiles que cela (on aurait pu faire les mêmes sur la liste de diffusion), il est important de rencontrer la communauté et de voir ce qui se fait ailleurs. Prosody se confirme comme serveur de choix, Buddycloud était intéressant à voir, et nous avons pu avoir des discussions très intéressantes avec Edhelas et Binary, et nos différentes façons de voir (on a eu un débat sur la neutralité de la technologie pendant notre visite de Berlin).
Sur le plan technique on a surtout pu montrer que nous étions plusieurs à nous intéresser à PubSub et à travailler avec/dessus, c'était notre but. Edhelas et moi avons décidé de travailler ensemble sur les bookmarks (marque-pages), je vais également finir mes 2 XEPs permettant d'utiliser un composant externe comme serveur PubSub, Matthew m'ayant confirmé son intérêt et son aide éventuel pour faire un module Prosody qui implémente ça.
Ce long journal était surtout là pour vous montrer un peu comment ça se passe de l'autre côté, que travailler sur des projets ce n'est pas que du code, c'est aussi des rencontres, des discussions, des façons de voir, des doutes, etc. Un projet communautaire, c'est avant tout une communauté ;) .
# Accords participes passés
Posté par Snark . Évalué à 2.
Journal très intéressant—mais il y a des soucis d'accords à différents endroits qu'il faudra régler avant de le promouvoir en dépêche! :-P
[^] # Re: Accords participes passés
Posté par Clément V . Évalué à 2.
Tant qu'on est dans les fautes, il me semble qu'il y a un "pas" en trop.
[^] # Re: Accords participes passés
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 16 septembre 2014 à 22:02.
C'est pour être sûr que ça ne dépasse pas les 400 lignes !
[^] # Re: Accords participes passés
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Ah mince, pourtant j'ai relu une fois, mais le texte étant long j'ai dû manquer d'attention, désolé.
# otalk
Posté par Anonyme . Évalué à 3.
en parlant de &yet, vous avez entendu parlé de otalk à Berlin ?
je crois que je suis tombé dessus suite aux articles sur Salut à Toi et Movim, mais je ne me souviens plus comment.
La combinaison XMPP + WebRTC me fait saliver (inconsciemment parce que cette réaction n'est basée sur aucune connaissance technique particulière, outre le fait que avec XMPP je gère la plateforme d'échange et avec WebRTC le lien entre deux interlocuteurs est direct)
Si tu y as jeté un coup d'œil, est ce que cela te semble prometteur ?
[^] # Re: otalk
Posté par Larry Cow . Évalué à 3.
XMPP + WebRTC, ce n'est pas exactement ce que fait Jappix pour la partie voix/vidéo?
[^] # Re: otalk
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Jappix et Movim oui
[^] # Re: otalk
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
et non je n'ai pas entendu parlé de otalk, mais je ne m'intéresse pas encore trop à la visio-conférence, on a d'autres choses à faire fonctionner correctement avant.
# on refait le protocole
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Une petite expérience de pensée: si vous deviez refaire un protocole depuis 0 aujourd'hui, est-ce que vous aboutiriez à un XMPP like ou à complètement autre chose?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: on refait le protocole
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 19 septembre 2014 à 14:30.
C'est difficile à dire parce que je ne suis pas à l'origine du protocole: y'a quelques défauts et de bonnes idées, les défauts étant principalement dans certaines XEPs, donc possibles à corriger.
Le choix souvent décrié de XML n'est pas mauvais à mon avis: c'est lisible, facile à lire, et il y a de base les espaces de nommage qui sont très utilisés en XMPP, la gestions des langues et c'est « hackable » simplement. Les parseurs sont disponibles partout, et j'aime beaucoup la simplicité de XMPP (seulement 3 stanzas:
<message/>et<presence/>qui sont évidents, et</iq>pour toute requête de type question/réponse).L'impossibilité d'envoyer du binaire directement que Psyc critique n'est pas un problème, vu que ça transite par un port différent, ce qui est plus logique à mon sens.
Le côté extensible, et la présence d'un écosystème important, la XSF et surtout ce qui va autour (les XEPs et listes de discussions) sont autant d'atouts majeurs (les 2 derniers ne sont pas liés directement au protocole, mais ça fait partie de XMPP). Ne pas avoir à s'occuper d'un serveur et ne pas partir de zéro nous ont permis d'aller très loin en étant peu sur nos projets.
Donc c'est un choix que je ne regrette toujours pas, maintenant si je devais le refaire je ne sais pas si j'arriverais au même résultat, mais je suis plutôt satisfait de ce qu'on a actuellement.
[^] # Re: on refait le protocole
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
markdown a mangé les noms des stanzas (pour ça que la phrase a l'air bizarre), il s'agit de <message/>, <presence/> qui sont évidents et <iq/> pour toute requête de type question/réponse.
[^] # Re: on refait le protocole
Posté par rakoo (site web personnel) . É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")
[^] # Re: on refait le protocole
Posté par Jehan (site web personnel, Mastodon) . É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 ]
[^] # Re: on refait le protocole
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
En lisant vos commentaires, je me demande si le http sous stéroïde (c'est à dire avec websockets et webrtc) ne serait pas la base choisie si xmpp n'existait pas.
On aurait ainsi une base pour:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: on refait le protocole
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
On peut se tutoyer, je pense. Depuis le temps qu'on traîne tous les deux sur ce site!
C'est malheureusement ce qui se passe de plus en plus. Et même XMPP commence à perdre du terrain là où il en avait gagné auparavant…
Ensuite est-ce que tu me dis ça parce que mon laïus sur "faire avec ce qui est là" laisse penser que je pense que c'est ce qui aurait dû arriver avec HTTP pour le chat et que ça aurait été un bien? Si c'est le cas, c'est pas ce que je voulais dire. Déjà je suis aussi un qui regrette beaucoup qu'on fait passer tout et n'importe quoi par HTTP (qui bien qu'au même niveau que XMPP est beaucoup moins pensé pour "tout et rien". XMPP a été pensé très générique, en tous cas dans ses dernières incarnations. Le design d'HTTP est vraiment orienté "page web", est assez peu efficace pour pas mal de choses, et tout le reste est un peu ajouté au dessus comme une grosse verrue avec des implémentations diverses et incompatibles). Ceci dit j'ai rien contre ceux qui développent activement dessus. Chacun son cheval de bataille et aux moins ils font quelque chose pour faire avancer sur leur centre d'intérêt! :-)
Mais surtout je pense que c'est très bien que des gens essayent autre chose et testent des nouveautés. Je suis tout pour la nouveauté et ouvert aux expérimentations. C'est d'ailleurs ce que je veux dire par "T'avais qu'à être le premier à faire un tel projet". Je n'ai rien contre ceux qui font vraiment quelque chose d'innovant. En général ceux là ne seront pas ceux qui cassent du sucre sur le dos de ce qui existe déjà. Ils peuvent soulever les limitations et comment ils prévoient de les dépasser dans le nouveau proto/logiciel, et en discuter, bien sûr. On s'est tous plaint un peu dans la vie, y a pas de mal à ça! Mais y a aussi ceux qui vont juste utiliser un peu sans comprendre vraiment les tenants et aboutissants, et qui vont finalement passer plus de temps et d'énergie à se plaindre et à dire "si c'était moi, j'aurais fait bien mieux" sans finalement jamais même démarrer à "faire". C'est contre-productif. Soit on fait avec ce qui est, soit on est certain d'avoir l'idée du siècle, et on la démarre. Ce qu'il y a entre-deux, c'est juste du brassage d'air et faire perdre du temps à tout le monde (à ceux qui utilisent sans se plaindre sans arrêt, comme à ceux qui innovent vraiment, comme à soi-même).
Ensuite c'est sûr qu'il vaut mieux un seul projet ouvert avec beaucoup d'utilisateurs/développeurs que des multitudes de projets qui ne décollent pas (en tous cas, dans le cas précis d'un tel protocole de communication), du moins dans le court/moyen terme. Mais pour le très long terme, il est aussi important qu'il existe quelques chiens errants qui décident de faire autrement, et qui soit mourront d'eux-même par inintérêt, soit se feront adopter un jour car on découvre que ce sont les meilleurs chiens du monde (certains chiens extraordinaires ne sont jamais découverts, ça arrive aussi)!
Voilà, en gros tout ce que je dis, c'est: arrêtons de se plaindre et faisons. Du neuf (le protocol du futur), du vieux (XMPP), du très vieux (HTTP), mais faisons.
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 Goffi (site web personnel, Mastodon) . Évalué à 4.
superbe commentaire, je pense le garder en référence pour ces critiques qui reviennent effectivement souvent, merci.
Et tout à fait d'accord sur le ça existe, c'est pas mal, ça fonctionne, on fait avec ! C'est à ça que je voulais en venir en disant que c'était une mauvaise idée de recommencer de zéro et de mettre au placard tout l'écosystème.
[^] # Re: on refait le protocole
Posté par rakoo (site web personnel) . É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.
[^] # Re: on refait le protocole
Posté par barmic . Évalué à 3.
Il a fallut que j'arrive au paragraphe sur le parsing pour comprendre que tu parle d'un champ/balise "to" (inverse de "from") et pas de tera octet.
Ou pas, il y a différentes manière d'analyser du XML. Certaines en flux ne nécessite pas d'analyser l'ensemble du XML pour récupérer une donnée qui est au début (comme les parseurs SAX par exemple).
Mais j'imagine bien que des couples clef/valeur lignes par ligne à la HTTP, c'est plus performant (même si c'est ou ça a était remis en cause pour HTTP 2.0).
Personnellement j'aime bien l'idée d'utiliser des canaux différents pour le binaire, ça permet un routage spécifique pour le binaire (si tu veux avoir un peu de qualité de service pour un flux vidéo c'est mieux) et en pratique l'énorme majorité des usages d'XMPP sont couverts par XML donc autant privilégier XML. Après ça peut être un frein au déploiement de XMPP, il faut des parefeux correctement configuré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: on refait le protocole
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 19 septembre 2014 à 13:50.
C'est pour ça que je précisais, je savais que ça pouvait en donner l'impression. :p
Ok, j'avais pas pigé cet aspect des choses. Continuons donc dans l'expérience de pensée.
Mouais, mon serveur connaît pas plus. Il demande au DNS à quel IP ça correspond, puis ensuite il transmet aux protocoles du dessous (TCP/IP) qui vont s'occuper de tout le transport et routage. Je vois vraiment pas où le serveur a fait du routage là.
Ben… c'est exactement la même chose que ton cas simple: 2 serveurs et 2 entités finales. C'est aussi la même chose que SMTP (dans le cas habituel où on envoie pas l'email directement au serveur final, ce qui est faisable mais peut être flaggué comme spam rapidement).
Franchement c'est pas du routage ça, ton cas encore plus "compliqué" avec IRC non plus. Ou alors très vite fait un routage de super haut niveau, qui utilise en vrai un routage bien plus réel de bas niveau. Mais bon le même que l'ensemble des protocoles du net de nos jours. Et encore, c'est tiré par les cheveux. Enfin je vois vraiment pas où tu veux en venir.
Ah d'ailleurs je viens de me souvenir du terme. On va plutôt appeler cela du "relai" à ce niveau de protocole. De même que le protocole SMTP fait aussi du "relai" de messages électroniques.
Moui, si tu as des milliers de ces petits morceaux (soit milliers de fichiers, soit un fichier si gros qu'il faut le couper beaucoup), ça va quand même boucher globalement la communication. Ensuite tu pourrais imaginer un système de priorité (réimplémenter un OS dans ton flux de données!) mais ça implique soudainement beaucoup plus de communication (le système de priorité ne peut pas être laissé au soin de l'envoyeur, sinon il fait ce qu'il veut et envoie toujours ses données en masse. Donc l'envoyeur attend que le destinataire lui donne le feu vert, cad lui envoie une requête "ok c'est bon, tu peux m'envoyer 2 paquets maintenant, mais pas plus"). Et puis ça va inutilement ralentir l'envoi du fichier par conséquent (déjà que les utilisateurs se plaignent que les chargements sont trop lents!) alors qu'on a des connexions de fous maintenant avec des bandes passantes suffisamment larges pour à la fois recevoir plein de données binaires et textuelles en parallèle sans percevoir le moindre ralentissement. Pourquoi faire compliqué, moins efficace, prône aux erreurs de protocole, d'implémentation hasardeuse et complexe, avec une sensation utilisateur "lente" à la fois pour l'envoi des binaires et le texte, etc. alors qu'on peut faire facile et efficace simplement avec deux flux parallèles (et on laisse l'OS gérer les I/O en simultané)? Je comprends même pas le but de la discussion. Ça apporte quoi que les données soient dans le flux? Je vois que des désavantages.
Bon c'est pas vrai: y en a qu'un seul d'avantage: si jamais on arrive pas à ouvrir un autre flux plus efficace (firewall, etc.), ben on n'a pas le choix. D'ailleurs je voudrais noter qu'il existe déjà depuis longtemps un tel transport binaire directement dans le flux, en base64, dans XMPP (transport "in-band" de Jingle). Mais franchement c'est à jamais utiliser si on a le choix de faire autrement (c'est d'ailleurs écrit clairement dans la XEP, c'est du "dernier recours" si on arrive pas à faire mieux). Proposer que ce genre de chose soit par défaut est d'après moi une aberration.
Donc analyse des données (comme je disais, on peut donner plusieurs sens à "parser". Le serveur va effectivement lire tout le stanza pour la "syntaxe", car c'est un flux, mais pas pour le "sens" nécessairement).
Ok dans ce cas là, ça tombe bien, oui le serveur s'arrête au header du stanza: le to bien sûr, mais aussi le from (vérifier que le from correspond bien à ce qui a été envoyé, je rappelle que XMPP est un protocole sécurisé et authentifié, pas comme SMTP, et donc qu'un serveur ne se contente pas de relayer des messages, il en vérifie notamment la provenance, la syntaxe, etc.), et éventuellement un chouille plus si nécessaire (par exemple le type, l'id si y a une réponse à renvoyer, etc.). Mais oui pourquoi le serveur irait analyser ce qu'il y a dans le stanza (à part si serveur de la NSA qui cherche des infos!)? Bien sûr que non, il ne va pas en extraire une "structure qui a du sens". C'est d'autant plus vrai que dans beaucoup de cas, il ne pourrait même pas. Je rappelle que XMPP est fait de plein de fonctionnalités, libre à chaque entité de les implémenter. Si on envoie une donnée particulière destinée à un client final, qui gère une fonctionnalité donnée, le serveur peut tout à fait ne pas avoir d'implémentation pour la dite-fonctionnalité. D'ailleurs la plupart du temps, les serveurs n'implémenteront pas les mêmes fonctionnalités (ou pas les mêmes bouts de la fonctionnalité) que les clients car ça n'a pas de sens. Donc le serveur se contente de relayer.
Et donc ça tombe bien, le serveur s'arrête au "to", sans chercher "le sens de ce qu'il y a en dessous" qu'il ne comprendrait probablement même pas de toutes façons puisque c'est une XEP pour clients. Ça se passe exactement comme tu veux! Donc un argument qui tombe!
Ok j'ai bien compris maintenant! ;-)
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 etenil . Évalué à 3.
Les gens de Diaspora sont en train de travailler sur Lime, un protocole asynchrone en JSON qui d'après eux est plus implémentable que XMPP.
Voir ici: http://limeprotocol.org/
[^] # Re: on refait le protocole
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Je ne comprends pas ce que veut dire « plus implémentable ». Si c'est pour « plus facile à implémenter », XMPP est très simple, c'est juste les multitudes de XEPs qui sont longues à implémenter, et là c'est un choix à faire selon ce qu'on veut. Ce qui prend du temps aussi c'est corriger/améliorer l'existant, mais c'est vrai pour tout protocole, et là le monde dessus et son âge lui donnent un avantage certain.
Donc faire un nouveau protocole pourquoi pas, mais je pense que c'est une erreur de repartir de zéro: comme dit plus haut l'ecosystème est un élément très important.
Faire un client XMPP de base est très simple (enfin si on a déjà un parseur XML sous la main, ce qui est le cas la plupart du temps).
Souhaitons leur bonne chance tout de même, et si c'est un trucs documenté ça permettra de faire une passerelle facilement…
[^] # Re: on refait le protocole
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Mmmh…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: on refait le protocole
Posté par lolcat . Évalué à 1. Dernière modification le 19 septembre 2014 à 01:20.
J'attendais de voir passer "Base64" dans ce thread. À votre avis c'est bien où mal ? C'est le même encodage que celui utilisé pour les pièces jointes des mails (en général, il y en a d'autres, mais c'est le plus courant je crois). Ça consiste à transformer un binaire en fichier ASCII, en gros en chaîne de caractère.
De très loin, comme ça, je n'ai pas l'impression que ce soit la manière la plus efficace de faire pour envoyer des binaires par le réseau, car en plus ça suppose des routines de codage/décodage.
Qu'en pensez vous ?
PS : j'allais ajouter que à mon avis c'est ingérable s'il faut gérer des flux vidéos et/ou audio continu.
[^] # Re: on refait le protocole
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Base64, l'un des principaux problèmes, c'est que ça augmente la taille d'un fichier d'environ le tiers. Donc déjà que les binaires peuvent être assez gros de nos jours (car souvent, ça implique des images, voire du son ou de la vidéo), ben là on envoie une version 1/3 plus grosse. C'est donc pas efficace.
La partie codage/décodage est très basique et n'est pas le problème. De nos jours, nos machines font plein d'autre codages beaucoup plus complexe sans qu'on s'en rende compte et en des temps tout à fait respectables. Note que d'autres choses peuvent augmenter la taille d'un fichier, par exemple si on chiffre la communication. Mais là c'est une perte de gain acceptée car ça a un intérêt (cacher les données). Par contre base64 n'a aucun autre intérêt que celui qu'on veut se forcer à passer par un canal texte pour transporter du binaire. D'ailleurs si on veut chiffrer tout en insérant notre fichier dans le canal texte, on chiffre d'abord puis on base64. Ça fait beaucoup d'overhead à la fin!
Non je pense vraiment que le vrai problème, c'est la taille, le temps que ça prend à charger, et par effet de bord, pour un flux de donnée, le fait que ça boucherait le tuyau.
Alors dans un email, c'est moins grave car ça n'a jamais été fait pour de l'instantané. Pour de l'instantané, je me demande comment cette équipe voit le mélange du binaire avec le reste. Ensuite j'ai pas lu du tout cette page. Je réponds juste à une pensée générale basé sur la seule phrase citée par devnewton. Peut-être qu'ils coupent le binaire en plein de petits bouts, comme rakoo dit plus haut, et mettent en place un système de priorité par exemple? Ou autre. Peut-être qu'ils ont d'autres idées intéressantes pour gérer cela. Ça devient super compliqué si tu pars dans ce genre d'idées ceci dit.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.