URL: https://linuxfr.org/users/goffi/journaux/de-l-autre-cote Title: De l'autre côté Authors: Goffi Date: 2014年12月16日T11:19:15+01:00 License: CC By-SA Tags: movim, xmpp, xsf, sàt, prosody, jappix et standard Score: 47 Salut à vous, ce journal fait plus ou moins suite à [celui sur le XMPP summit à Berlin](https://linuxfr.org/users/goffi/journaux/retour-de-berlin). C'est un peu technique mais ça devrait être compréhensible. L'idée est de montrer comment ça se passe de l'autre côté du logiciel. Donc pour résumer: nous sommes plus ou moins 4 (Binary un développeur russe, Edhelas de Movim, et Souliane et moi de « Salut à Toi ») à essayer de pousser PubSub (Publish Subscribe) en XMPP pour corriger les derniers problèmes et avoir un système de (micro)blogage décentralisés. Au niveau de « Salut à Toi » (SàT par la suite), nous avons décidé que nous passerions nos propres blogs sur le projet pour la prochaine version. La XEP de Binary est passé en « experimental » (première phase vers la standardisation) et porte le numéro [0351](http://xmpp.org/extensions/xep-0351.html). De mon côté j'avais publié une première XEP: « privileged component », et j'en avais une deuxième prévue. Avant de parler des XEP, expliquons un peu le problème: PubSub est un peu le parent pauvre de XMPP. La XEP est conséquente, peu de serveurs l'implémentent complètement, et il nous manque presque toujours une fonctionnalité pour pouvoir l'utiliser avec nos projets. Notamment, pour le microblogage, il faut implémenter « [Personal Eventint Protocol](http://xmpp.org/extensions/xep-0163.html) » (PEP), une version simplifiée de [PubSub](http://xmpp.org/extensions/xep-0060.html), et qui permet en particulier d'avoir un service PubSub par compte (pour être plus clair: normalement il faut trouver un « nœud », une sorte d'adresse, pour accéder à un service PubSub, avec PEP il suffit d'avoir son jabber id (jid) soit une information qu'on a déjà quand on connait le contact). L'implémentation de PEP pose problème sur pratiquement tous les serveurs: soit c'est lent, soit incomplet, soit les 2 :). En plus de cela sur SàT nous implémentons une fonctionnalité non standard (pour le moment) qui permet d'envoyer des microblogs à un groupe en particulier (uniquement les amis ou uniquement la famille par exemple), l'équivalent des « cercles » ou des « aspects » qu'on trouve par ailleurs. Pour résoudre ce problème, il y a principalement 2 options: se concentrer sur un serveur avec une équipe de dév à l'écoute, c'est ce que font Jappix et Movim en recommandant [Metronome](http://www.lightwitch.org/metronome) (même s'ils fonctionnent plus ou moins avec d'autres serveurs), ou alors faire un service PubSub/PEP indépendant du serveur qui implémente tout ce dont on a besoin, c'est ce que nous avons choisi pour SàT. Côté service PubSub, nous avons eu de la chance en ayant une bonne base avec [Idavoll](https://idavoll.ik.nu/), une implémentation de PubSub faite par Ralph Meijer lui même (un des auteurs de la XEP PubSub), utilisée notamment par Apple pour les notifications dans Mac OS X, et qui en plus utilise les mêmes technologies que SàT ([Twisted](http://twistedmatrix.com/) et [Wokkel](https://wokkel.ik.nu/) - du même auteur -). Le projet n'est plus actif, et nous voulions implémenter des choses non standards, aussi nous l'avons forké dans le projet [SàT PubSub](http://repos.goffi.org/sat_pubsub). Nous avons donc notre service PubSub qui implémente ce que l'ont veut, mais comment l'interfacer avec les serveurs XMPP ? XMPP définit un protocol pour « brancher » un service (un composant) sur un serveur, c'est la [XEP-0114](http://xmpp.org/extensions/xep-0114.html). Le problème est que c'est aussi limité qu'un client normal (or il nous faut accéder à des données sensibles comme les contacts - ou roster - d'une entité), et que ça ne permet pas de remplacer le service PEP du serveur lui même: c'est impossible avec les XEPs actuelles de XMPP. Notre première solution, actuellement en place sur la dernière version de SàT, était d'utiliser des bidouilles avec Prosody: détourner un module existant (remote-roster) pour accéder au roster d'un contact, et simuler PEP en associant un nœud à une entité. Problème: c'est sale, et ça n'est plus standard, donc nous ne pouvons pas communiquer avec Movim et Jappix. L'autre solution, que nous avions en tête depuis très longtemps mais il fallait trouver le temps, c'était d'écrire les XEPs qui nous manquent pour faire les choses proprement. Ces XEPs sont donc 2: « privileged entity » qui permet de donner des permissions importantes à une entité, et « namespace delegation » qui permet de faire traiter par une entité externe un espace de nommage normalement réservé au serveur (PEP dans le cas qui nous intéresse). L'écriture d'une XEP est un exercice peu amusant, et qui demande une certaine rigueur. Il faut penser aux problèmes d'implémentation, de sécurité, etc. Il faut être ouvert aux critiques qui ne manqueront pas sur la liste « [standard](http://mail.jabber.org/mailman/listinfo/standards) ». La tradition veut que l'ont utilise les personnages de « Romeo et Juliette » pour donner les exemples. Des conseils de style sont donnés dans la [XEP-0143](http://xmpp.org/extensions/xep-0114.html), et on télécharge [sur le dépôt XMPP](git://gitorious.org/xmpp/xmpp.git) les sources des autres XEP que l'on peut utiliser comme modèle, ainsi que le fichier xep.xsl qui permet la transformation via [[XSLT]] en XHTML. J'ai écrit sur mon blog [un billet qui donne une astuce pour avoir l'aperçu en temps réél, en utilisant Konqueror, D-Bus et inotify](http://www.goffi.org/post/2014/10/24/Astuce-du-jour%3A-utiliser-Konqueror-pour-avoir-un-aper%C3%A7u-temps-r%C3%A9el.). Une fois une première version obtenue, on la soumet à la XSF en envoyant un courriel à l'« editor team », qui place alors la XEP dans [le dossier inbox](http://xmpp.org/extensions/inbox/) en attendant que son statut soit décidé à une réunion XSF. Il faut indiquer explicitement qu'on possède les droits sur la XEP et qu'on les donne à la XSF, afin que celle-ci puisse publier sous licence libre. Ceci s'accompagne d'un message sur la liste standard, et des premières réactions qui sont [parfois enthousiastes](http://mail.jabber.org/pipermail/standards/2014-September/029187.html), parfois moins, et qui s'accompagnent en général de critiques techniques/corrections à apporter ou discuter. Ensuite c'est l'attente d'une réunion du « council » qui décidera par consensus si la XEP peut passer à l'état « experimental » et ainsi avoir un numéro officiel. En attendant, on peut renvoyer des versions mises à jour en fonction des retours, qui s'accompagneront d'un nouveau message sur standard et de nouveaux retours. J'ai dû rappeler plusieurs fois sur le salon de la XSF qu'on était dans l'attente d'une évolution pour les XEP. La semaine dernière, il y a enfin eu une réponse de la XSF:> 4) Accept http://xmpp.org/extensions/inbox/namespace-delegation.html> as Experimental?> Dave and Fippo +1, Lance, Kev and Matt to vote onlist> > 5) Accept http://xmpp.org/extensions/inbox/privilege-component.html as> Experimental?> Kev, Lance, Fippo, Matt to vote onlist. Dave -1 to post> reasons/resolutions to standards@ Traduction: « namespace delegation » ils sont plutôt favorables mais on attend encore des votes, « privileged entity » Dave a mis un veto (le -1), et doit fournir des explications sur ce qui le dérange. Nous sommes à plusieurs mois depuis le début de l'écriture des XEP, et c'est bien sûr très décevant de voir un veto sur l'une d'elles. Bien que nous n'ayons pas encore les explications officielles, j'ai pu discuter avec Dave sur le salon de la XSF, ce qui le dérange c'est qu'il y a déjà des XEP qui gèrent des permissions à un autre niveau, comme [security labels](http://xmpp.org/extensions/xep-0258.html) et qu'il pense qu'il faudrait unifier tout ça sur un standard existant, comme [[XACML]]. C'est une remarque sensée, mais j'ai peur qu'on n'ait pas de solution avant des années avec un protocole aussi complexe à intégrer, alors qu'une XEP comme la mienne peut toujours devenir obsolète une fois une meilleure solution disponible. Voilà où on en est, on attend encore du mouvement de la XSF pour savoir quoi faire, et après il faudra penser aux premières implémentations expérimentales (dans Prosody), puis à l'implémentation dans SàT. La partie code n'a pas encore été touchée et il y a déjà eu beaucoup de travail, mais c'est le prix à payer si on veut faire les choses proprement et durablement. En même temps, nous avons repris contact avec Ralph Meijer pour essayer de remettre sur pieds Idavoll: nous aimerions un service PubSub générique utilisable par tous les projets, pas uniquement par SàT, et tous les serveurs. Notre stratégie est d'expérimenter dans SàT PubSub, et de remonter dans Idavoll une fois les choses standardisées et propres. Nous cherchons à remonter du code de SàT vers Wokkel également. Encore un long journal, je ne sais pas si ce genre de journaux techniques vous intéressent. La prochaine fois je pourrai vous parler de nos déboires avec Pyjamas (Transpileur Python/Javascript) et de notre besoin de factoriser le code entre les frontaux.

AltStyle によって変換されたページ (->オリジナル) /