goffi goffi

Cagou: XMPP based social network on its way to reach your desktop and Android

Hi to you,

It's time for a blog post on Cagou development.
Cagou is the new desktop/Android frontend for "Salut à Toi" (SàT), the full-featured social network based on standards (XMPP) and with a strong emphasis on ethics.

This frontend is using the very nice Kivy framework, and is already usable on desktop.

Let's see a video on the current state:

As you can see, the interface can be divided easily. This idea is inspired by the excellent Blender interface, and make it easy to adapt to a small or big screen by choosing the number of widgets accordingly.
Instead of being a discreet software that you'll use only when you want to answer to somebody, Cagou is an application which should be used full-screen, with a layout suiting the current needs.

Other important point: the contact list is not the central element (as it is usually in instant messaging software). You can access it by selecting the widget, or put it on the side to simulate traditional layout, but it is not visible by default and you can spend a whole session without using it.

widget selection

About notifications, it will be slighly different on desktop and on platforms with their own notification system (like Android). In the later case, the native way will be used.
On desktop, a specific header is used. 2 cagou icons (thanks to Muchoslava for its contributions) can appear: one on the left for notes (i.e. short messages which will automatically disappear), and one of the right for more important notifications, needing attention from the user.
A click on the left icon will show the last 10 notes, and one the right one show the next important notification.

This was made to avoid popups: they are displayed only after an interaction of user, and will not appear all of a sudden while you are writting a message.

notification example

Thanks to the architecture of SàT, menus are already available with a couple of useful actions.

There are several ways to start a chat: you can click on an item in the contact list, or enter a jid (XMPP identifier) in a chat widget.
Discussions are not closed when you switch widget, and they can be later accessed by swiping the current one (see video below).

There have been a lot of work done and the interface starts to be really usable. Concerning the desktop the greatest part is already finished, the most important remaining thing is to adapt interface to features (e.g. displaying of delivery reciept) and to make new widgets.

The other big thing to cope with would be displaying of HTML content and of course the Android port. An Ubuntu touch port is an eventuality.

And for those who wonder: Cagou will as well benefit from end-to-end encryption (for now OTR, but OpenPGP is planned for next release, OMEMO is considerated), and other SàT features

The project is still in active progress, but it is really demanding. If you can contribue in any way – code, distributions packages, tests, graphics, translations, etc. – please contact us by any mean shown on our website.

Last but not least, we reminds all of the Aziruka contributors of the crowdfunding campaign, that they can claim their counterpart if not done yet (or request it later).

See you soon :-)

Premiers jappements de Cagou

Salut à vous,

Cagou commençant à prendre sérieusement forme, il est temps de faire un billet sur l'avancement.

Avant le début du développement de l'interface elle-même, des changements nécessaires ont été faits en particulier sur la gestion des messages. Outre la gestion des langues dont j'ai parlé dans des précédents billets, le plus important est que nous pouvons désormais changer l'état d'un message après réception, ou y faire référence. Ceci permet d'implémenter des fonctionnalités comme les accusés de réception, ce qui a été fait par une contribution de Chteufleur (merci :)). D'autres fonctionnalités qui attendaient comme la correction du dernier message vont bientôt pouvoir suivre.

Il était nécessaire de faire ce travail avant d'implémenter la messagerie instantanée sur Cagou, pour pouvoir partir sur de bonnes bases.

Ensuite il a fallu intégrer l'interface sous Kivy à SàT, et en particulier D-Bus et QuickFrontend, notre modèle pour faire des frontaux en Python.

Tout ceci s'est relativement bien passé, et voici une petite vidéo pour vous mettre en appétit :

Quelques explications maintenant.

Comme vous le voyez, l'interface peut-être divisée facilement. Cette idée est inspirée de l'excellente interface de Blender, et permettra de s'adapter facilement à un petit ou grand écran en choisissant le nombre de widgets et leur disposition.
Au lieu d'être un logiciel discret qu'on utilise uniquement quand on veut répondre à quelqu'un, Cagou est une interface qui s'utilise principalement en plein écran, avec une disposition adaptée à la situation et les outils importants directement visibles (si la taille de l'écran le permet).

Autre point important, la liste de contacts n'est pas l'élément central comme c'est souvent le cas dans les logiciels de messagerie. Vous pouvez y accéder en sélectionnant le widget, voire la mettre sur le côté pour reproduire le comportement traditionnel, mais elle n'est pas affichée par défaut et n'est pas indispensable.

sélection de widget

Tous les widgets sont des greffons, a terme il devrait être possible d'en télécharger, ou de changer complément le fonctionnement d'un widget de base. Comme effet de bord, et surtout grâce au travail de l'équipe derrière Kivy, Cagou sera une plate-forme qui permettra d'échanger facilement des scripts Python sur Android (reste à voir comment on va gérer les permissions).

En ce qui concerne les notifications, le fonctionnement va être différent sur bureau et sur les plates-formes qui ont déjà un système de notification (comme Android). Dans ce dernier cas, le système de la plate-forme va être utilisé.
Sur bureau, un en-tête spécifique est utilisé. 2 icônes de Cagou (merci à Muchoslava pour ses contributions) peuvent apparaître : une à gauche pour les notes (c.-à-.d les messages court qui ne s'affichent que quelques secondes), et une à droite pour les notifications plus importantes, nécessitant l'action de l'utilisateur.
Un clique sur l’icône de gauche permet d'afficher les 10 dernières notes, et un sur l’icône de droite affiche la notification importante suivante.

Ceci a été pensé pour éviter les popups, ces dernières ne sont affichées que suite à une action de l'utilisateur, et n’apparaissent pas d'elles même si un quelconque événement les déclenche.

exemple de notification

Les menus ont également été implémentés, ils apparaissent en haut sur bureau. Sur petits écrans (téléphones), ils ne seront sûrement visibles que suite à l'appui de la touche idoine.

Grâce au fonctionnement de Salut à Toi, ceux-ci permettent déjà de faire des actions de base comme ajouter ou modifier un contact et avancées comme piloter son serveur.

Enfin le lancement d'une conversation peut se faire de plusieurs manières. On peut en commencer une en cliquant sur un contact dans le widget « liste de contacts », ou en tapant son jid dans un widget « chat » (il devrait rapidement être possible de taper quelques lettres pour avoir les suggestions). Les conversations ne se ferment pas quand on change de widget, on peut accéder aux conversations en cours en faisant passer son doigt (ou sa souris pendant un clique) rapidement vers la droite ou la gauche, cf. la vidéo ci-dessous. Il sera bientôt possible de les fermer via un menu dédié.

Voilà l'état des lieux actuel. Il y a déjà eu beaucoup de travail, et l'interface commence à être vraiment utilisable. Côté bureau le plus gros est fait, il s'agit maintenant d'adapter l'interface aux fonctionnalités (afficher l'accusé de réception par exemple), et à faire de nouveaux widgets. Un gros morceau reste toutefois l'affichage du contenu HTML, vu que ça n'est pas géré de base par Kivy (mais il y a différentes solutions possibles).

En ce qui concerne Android, il va y avoir une partie qui risque d'être un peu difficile pour faire le port, mais je ne m'inquiète pas plus que ça.

J'envisage également de faire un port sur Ubuntu Touch, j'ai commandé à cette fin une tablette d'occasion qui devrait me permettre de l'installer (ce n'est pas une promesse, juste une éventualité).

Ah et bien sûr, Cagou va profiter des fonctionnalités de SàT, y compris le chiffrement de bout en bout (OTR pour le moment, mais OpenPGP est envisagé pour la 0.7, et peut-être OMEMO également).

Petite note pour les programmeurs : une fois la prise en main passée (qui n'est pas très difficile), j'apprécie beaucoup travailler avec Kivy, c'est souple, agréable à utiliser et ça fonctionne jusqu'ici très bien, félicitation aux équipes derrière.

Je conclus sur une bouteille à la mer : c'est un travail absolument énorme de travailler sur SàT, et à l'heure actuelle je suis pratiquement seul dessus, et en plus de mon emploi salarié. Le projet avance toujours à bon train, mais j'ai besoin d'aide. La base de code est importante, mais il n'est pas insurmontable de s'y mettre : Chteufleur mentionné plus haut a pu rapidement écrire des greffons et a fait les implémentations des XEP-0070 et XEP-0184.

Il est aussi possible de contribuer en dehors du code : empaquetage pour des distributions, tests, graphismes, traductions, installation de serveurs, etc. Contribuer à une bibliothèque utilisée par SàT (comme l'implémentation de XMPP dans Twisted ou Kivy) est également très utile.

Au passage, je rappelle à ceux qui ont participé à la campagne de financement, qu'ils peuvent nous contacter sur « contact chez salut-a-toi point org » pour réclamer leur contrepartie, ou la demander plus tard s'ils préfèrent.

À très bientôt pour la suite :)

Libervia (Salut à Toi) 0.6.1: XMPP blogging and more

The 0.6.1 release of Libervia (Salut à Toi) is out, and it is a big one (despite of the minor version number).
The one which will follow — and is already well advanced — will be the « general public » release, or in other words we'll do what is necessary to have a release stable enough to be used seriously, and easy enough to install so the large public can enjoy it.

You can have a look at the changelog or the repository for more details, but here are the main changes and fixes:

  • import plugin which can be extended, with "importers" for Dotclear and DokuWiki. Please note that, thanks to the use of standards, this can be useful even if you're not using Libervia to display your blog (it's compatible with Movim for instance)

  • in addition to the Dotclear import, its wiki syntax is available for SàT too, it comes with the already available Markdown and XHTML.

  • automatic subscription to PubSub feeds for new accounts, this avoids an empty pages for newcomers

  • MAM (XEP-0313) is implemented for PubSub, this allows to go back in publication history and to search in a more flexible and powerful way. Note that MAM is not available yet for instant messaging, it's planed for 0.7

  • better detection of repository revision

  • jp (CLI) has now an option --output with who you can specify the output format (e.g. JSON so parsing by an other command is easy).

  • jp: new command to import a blog (import), (re-)edit a new/old publication (edit) or have a preview in real time (preview). We have published a tutorial in french to explain how to publish on your XMPP blog with Vim, Emacs or whatever else, any help to translate to English welcome

  • jp: commands to manage your roster: get it (get), have statistic on it (stats), or clean it (purge)

  • jp: the command "message" has been moved to "message send" to be coherent with other commands, and because a "message get" should come in the future

  • Primitivus (console interface): paste detection (a validation is needed in this case, this avoid sending a bad text like a password by mistake), and handling of "bracketed paste mode"

  • Libervia (web interface): a new option "allow_registration" allows to deactivate the new account registration page, specially useful if you are alone on your instance, or if you create accounts by your own means

  • Libervia: a new pop-up with a counter is displayed if connection with server is lost

  • Libervia: new favicon with a notification counter

  • Libervia: connection with an external jid is fixed

  • Libervia: it is now possible to redirect pages or to integrate a local directory in Libervia. That's used to display directly the blog instead of the login page on www.goffi.org.

  • Libervia: TLS chains are now handled (hello Let's Encrypt)

  • Libervia (blog): tags are now handled, including search

  • we have also updated and improved our Docker images, so you can easily install and test Libervia. Please check the wiki page with the explanations.

This is a summary of 0.6.1, but it is not covering everything!

Salut à Toi is an ethical project is staying away from big proprietary companies, if you feel like helping it contact us by email (contact at salut-a-toi d.o.t org) or on our XMPP MUC room. We need more hands!

The 0.6.1 is the last one before the "general public" one and has its issues to be improved. Don't hesitate to report them so that the 0.7 will be rock solid :)

The 0.7 will go through beta testing phase, and will bring in particular:

  • refactoring of messages, which will be needed to implement a lot of extensions which were blocked until now, like last message correction, or server side messages archives (MAM). This part is already finished, and you can see below an example of an experimental language detection plugin for Primitivus (based on langid):

language detection and filtering on Primitivus

  • Cagou, the new desktop/mobile devices frontend that we have promised after the success on our crowdfunding campain. The development is advanced, a post about it should arrive soon.

  • blog and messaging gateways

Beside all this, there is a good probability that we implement new end 2 end encryption system, in addition to the already available OTR. We specially think about OpenPGP and OMEMO.

Salut à Toi 0.6.1

Salut à tous,

la version 0.6.1 de Salut à Toi vient de sortir, et elle est conséquente malgré son numéro de version mineur. La prochaine version — qui est déjà bien entamée — sera la version « grand public » que nous annonçons depuis des années, autrement dit une version que nous voulons suffisamment stable pour être utilisée au quotidien, et suffisamment facile à installer pour être disponible pour un large public.

Vous pouvez toujours vous référer au journal des modifications (changelog) ou au dépôt pour avoir le détail, mais voici quelques unes des nouveautés et corrections principales :

  • plugin d'import extensible avec « importeurs » pour Dotclear et DokuWiki. Notez bien que grâce à l’utilisation des standards, ça peut vous être utile même si vous n’utilisez pas SàT pour afficher votre blog (c’est compatible avec Movim par exemple)
  • en plus de l'import Dotclear, la syntaxe wiki Dotclear est également disponible avec SàT désormais, elle vient s’ajouter à Markdown et XHTML.
  • inscription automatique à un flux PubSub pour les nouveaux comptes, ce qui évite d'arriver sur une page vide
  • MAM (XEP-0313) est implémentée pour PubSub, ce qui permet de remonter dans les articles et de faire des recherches de manière beaucoup plus souple et puissante. Notez que MAM n’est pas encore disponible pour la messagerie instantanée, ce sera le cas pour la 0.7
  • meilleure détection de la version du dépôt utilisée
  • jp (l’interface en ligne de commande) a désormais une option --output qui permet de spécifier le format de sortie (par exemple du JSON ce qui permet de facilement parser le résultat avec une autre commande). C’est encore peu utilisé mais la base est là.
  • jp : nouvelles commandes pour importer un blog (import), (ré-)éditer un nouveau/ancien billet (edit) ou voir l’aperçu mis à jour en temps réel (preview). Pour plus d’infos, référez-vous au billet d’explication qui montre comment publier sur votre blog avec Vim ou autre
  • jp : des nouvelles commandes également pour la gestion du roster, qui permettent de l’afficher (get), d’avoir des statistiques (stats) ou de le nettoyer (purge)
  • jp : la commande « message » a été déplacée vers « message send » par cohérence avec les autres commandes, et parce qu’un « message get » est à prévoir
  • jp : les codes de retour utilisent maintenant des constantes, afin qu’ils soient plus utiles
  • Primitivus (interface console) : détection d’un « coller » (une validation est nécessaire dans ce cas, ce qui évite l’envoi accidentel d’un mauvais message comme un mot de passe copié peu avant) et gestion du mode « bracketed paste »
  • Libervia (interface web) : une nouvelle option « allow_registration » permet de désactiver la création de nouveaux comptes, pratique si vous êtes seul sur votre instance, ou si vous créez les comptes par vos propres moyens
  • Libervia : affichage d’un message avec compteur en cas de perte de connexion avec le serveur
  • Libervia : utilisation d’une nouvelle favicon avec un compteur de notifications visible
  • Libervia : correction de la connexion avec un compte (jid) extérieur. Cette fonctionnalité très demandée nous avait causé de gros problèmes à la sortie de la 0.6.0, ils devraient être désormais réglés.
  • Libervia : il est maintenant possible de rediriger les pages ou d'intégrer un répertoire local dans Libervia. C’est ce qui permet d’afficher directement le blog au lieu de la page d’enregistrement sur www.goffi.org.
  • Libervia : gestion des chaînes TLS (Let's Encrypt, si tu nous lis…)
  • Libervia (blog): gestion des étiquettes (tags), y compris la recherche

Voilà pour un aperçu, et c’est loin de couvrir toutes les améliorations de la 0.6.1.

En lisant ceci vous aurez peut-être une petite idée de la quantité de travail nécessaire pour faire avancer un projet comme celui-ci, sachant que nous ne sommes que 2 (et que pour la 0.7 je suis pratiquement tout seul). Aussi si vous voulez participer à un projet éthique et qui refuse de céder aux sirènes des grosses entreprises privatristes, contactez-nous (contact at salut-a-toi point org) ! Rejoignez-nous sur notre salon MUC ! Venez nous aider, on en a grand besoin !

La version 0.6.1 n’est pas parfaite, elle a quelques problèmes (connus ou non), mais nous avons préféré sortir cette version qui malgré tout fonctionne, pour nous concentrer sur la 0.7, qui sera la première version « grand public », annoncée depuis des années.

La version 0.7 passera par une phase de bêta test, et devrait apporter en particulier :

  • un ré-usinage des messages qui permettra d’implémenter de nombreuses extensions bloquées jusqu’ici, comme la correction du dernier message, ou les archives côté serveur (MAM). Cette partie est déjà finie

  • Cagou, l'interface bureau/appareils portatifs que nous avons promis suite au succès de notre campagne de financement participatif. Le développement est bien avancé, bientôt un billet sur le sujet

  • des passerelles de messagerie et de blog. Cela fait longtemps qu'on parle d'en faire, les premières devraient voir le jour dès que Cagou est disponible

En dehors de ça, il est probable que nous implémentions de nouveaux systèmes de chiffrement de bout en bout, en plus d'OTR qui est déjà disponible. OpenPGP est visé en particulier, ainsi qu'OMEMO.

Les grosses fonctionnalités comme l’organisation d’événements ou les calendriers partagés sont plutôt envisagées pour la version suivante.

Ah, et la nouvelle version est disponible comme d’habitude sur le FTP, sur PyPi ou directement depuis le dépôt.

guide : écrire un greffon pour SàT

Cela fait plusieurs fois qu’on me demande comment contribuer à SàT, le projet étant conséquent il n’est pas facile d’accès. Aussi voici un article d’introduction pour l’écriture d’un greffon pour le backend.

Il est très utile d’avoir lu l'article d’introduction sur l’architecture de SàT avant. L’intérêt de faire un greffon backend est qu’il fonctionnera avec tous les frontaux, autrement dit sur le web, sur le bureau, sur appareils portables (bientôt) voire en ligne de commande ou autre.

Nous allons faire un classique « Salut à Toi le monde ! » bien connu des développeurs.

avant de commencer, quelques remarques en vrac

Quelques remarques et notions utiles à savoir, ne vous inquiétez pas si vous ne comprenez pas tout du premier coup :

  • SàT est actuellement en Python 2, le passage à Python 3 ayant été bloqué principalement par Twisted jusqu’ici. Mais les choses ont beaucoup avancé récemment, et Twisted fonctionne désormais partiellement avec Python 3, la partie XMPP est aussi en cours de portage, et le passage à Python 3 pourra être envisagé pour SàT 0.8 (après la version « grand public » donc).

  • le style de code suit à peu près les conventions de la PEP 8, mais pas entièrement. En particulier les noms de méthodes utilisent le CamelCase pour rester cohérent avec le code de Twisted, et la limite des 80 caractères n’est pas respectée (il n’est pas impossible que cela change dans le futur), vous aurez plus de détails sur le wiki (notez bien la partie sur les docstrings).

  • le backend de SàT est entièrement asynchrone, en utilisant Twisted. C’est probablement le plus difficile à appréhender pour un débutant, et vous pouvez commencer en regardant comment font les autres parties du code pour comprendre les grandes lignes. La chose la plus importante à retenir est qu’il ne faut jamais faire de code « bloquant », c’est-à-dire long à s’exécuter, car ça bloquera tout le backend. S’il est indispensable de bloquer pour une raison ou une autre (un module tiers à utiliser par exemple), vous devrez utiliser des processus séparés. La documentation sur le site mentionné est relativement fournie quand vous vous sentirez d’approfondir le domaine…

  • la hierarchie du code (src) est actuellement comme suit:

    • bridge gère la communication avec les frontaux, c’est l'IPC (actuellement D-Bus mais d’autres options sont possibles)
    • core contient comme son nom l’indique le cœur du backend (le « Service » SàT, le client XMPP, les constantes, les exceptions spécifiques à SàT, la gestion des logs et de la traduction)
    • memory gère tout ce qui est conservation des données que ce soit en mémoire vive ou sur disque (via Sqlite pour le moment, mais d’autres options sont possibles)
    • plugins contient… les greffons, c’est à eux que l’on va s’intéresser par la suite
    • stdui contient les interfaces XMLUI de base (nous reparlerons de XMLUI plus bas)
    • test est le répertoire où sont comme vous vous en doutez les tests unitaires ou autre.
    • tmp est une hiérarchie que nous avons dû créer pour mettre du code temporaire destiné à être intégré par des projets tiers que nous utilisons, en particulier Wokkel à l’heure actuelle
    • tools est la hiérarchie un peu « fourre-tout » pour les choses utiles, en particulier XMLUI et les triggers dont nous reparlerons plus tard. La sous-hiérarchie « common » contient les modules utilisés/ables à la fois par le backend et les frontaux.
    • twisted enfin est uniquement utilisé pour l’intégration à Twisted
  • on parle souvent de profil (profile en anglais et dans le code) qui correspond à un compte XMPP.
    En mode mono-utilisateur (Primitivus ou Cagou par exemple), cela peut correspondre à plusieurs comptes d’un même utilisateur (par exemple j’ai un profil jabberfr et un autre libervia.org pour mes 2 comptes correspondant). En mode multi-utilisateur (avec Libervia par exemple), cela correspond à des comptes d’utilisateurs différents.

  • à la notion de « profile » s’ajoute celle de « profile_key ». C’est en fait en mot clef qui indique un profil à utiliser (vous les trouverez dans les constantes avec PROF_KEY_XXX). En particulier PROF_KEY_DEFAULT indique d’utiliser le profil par défaut, et PROF_KEY_NONE indique une valeur non renseignée qui provoquera une exception si elle est utilisée avec getClient (voir plus bas).

  • dans les classes, on utilise souvent un attribut « host » (self.host la plupart du temps), qui correspond à l’instance du service SàT, et qui permet d'accéder à beaucoup de choses (le « bridge », la partie « memory », etc).

  • dans les méthodes, vous verrez souvent les paramètres « client » ou « profile ». « profile » correspond au nom du profil dont on a parlé plus haut, et client à l’instance du client XMPP et donc à la session associée à ce profil.
    On passe du profil au client en faisant « host.getClient(profile) » et du client au profil en faisant « client.profile ».
    Avant « profile » était systématiquement utilisé et placé en dernier paramètre (avec une valeur par défaut de C.PROF_KEY_NONE qui indique une valeur non renseignée). Désormais il a été décidé de toujours utiliser client comme premier argument, et profile uniquement quand c’est nécessaire (à l’entrée ou la sortie du « bridge » par exemple), aussi le code passe petit à petit à la nouvelle convention, et vous pouvez voir les 2 cas.

  • en début de fichier, il est souvent utile de faire ces imports :

    from sat.core.constants import Const as C
    from sat.core.i18n import _, D_
    from sat.core.log import getLogger
    log = getLogger(__name__)
    from sat.core import exceptions
    

    La première ligne permet d’accéder aux constantes, avec C pour que ça reste court et lisible.
    La seconde importe la fonction gettext « _ » qui traduit le texte dans la langue locale au moment de son utilisation, et « D_ » qui indique qu’un texte est à traduire, mais que la traduction aura lieu plus tard dynamiquement (utile pour un menu par exemple, qu’on peut traduire différemment selon les profils).
    Les 2 suivantes instancient un loggeur qu’on peut utiliser assez classiquement avec log.[niveau](message), par exemple log.debug(u"mon message de debug")
    Enfin la dernière ligne permet d’utiliser les exceptions spécifiques à SàT, vous pouvez lire le code du module idoine pour plus d’infos.

Avec tout ça on a l’essentiel pour s’attaquer au code.

création du fichier et déclaration du plugin

La première chose à faire est de créer un fichier python dans le répertoire plugins et dont le nom commence par "plugin_".
De tels fichiers sont automatiquement importés par le backend au démarrage, et à terme il devrait être possible de les mettre ailleurs (par exemple dans un dossier personnel) et de les télécharger et installer automatiquement.
Vous constaterez que les greffons existant sont nommés avec leur type puis leur nom, et que ceux qui implémentent des XEPs prennent le nom de la XEP (par exemple plugin_xep_0045.py).

Nous allons maintenant déclarer le greffon, pour delà nous utilisons une variable (un dictionnaire) nommée PLUGIN_INFO et placée en début de fichier. Voici un exemple d’en-tête avec celui du greffon XEP-0045 (le salon de groupe MUC) :

PLUGIN_INFO = {
    "name": "XEP-0045 Plugin",
    "import_name": "XEP-0045",
    "type": "XEP",
    "protocols": ["XEP-0045"],
    "dependencies": [],
    "recommendations": [C.TEXT_CMDS],
    "main": "XEP_0045",
    "handler": "yes",
    "description": _(u"""Implementation of Multi-User Chat""")
}

voici les informations données:

  • name : nom « lisible par un humain » donné au greffon
  • import_name : nom court utilisé pour référencer ce greffon par ailleurs (depuis d’autres greffons par exemple) pour accéder à ce greffon par la suite, vous pourrez utiliser host.plugins[nom d'import], ainsi ici vous pourrez faire host.plugins["XEP-0045"]
  • type : une information sur ce que qui est implémenté ; est-ce une XEP (type "XEP"), ou expérimentation (type "EXP") ? L’information n’est pas encore utilisée, mais elle devrait permettre de filtrer les greffons à l’avenir, quand ils seront téléchargeables depuis un dépôt. Les types courants ont leur constante de la forme PLUG_TYPE_*
  • protocols : une liste de protocoles implémenté le cas échéant. Les XEP sont toujours référencées sous la forme XEP-0xxx avec « XEP » en majuscules.
  • dependencies : autres greffons indispensables pour faire fonctionner celui-ci. C'est une liste de noms correspondant au « import_name » voulus. Ces greffons seront importés avant celui en cours, et s’ils ne sont pas disponibles l'import échouera
  • recommendations : greffons non indispensable pour faire fonctionner celui en cours, mais qui apportent des améliorations si présents. Fonctionne de la même manière que dependencies sauf que l'import n’échouera pas si ces greffons ne sont pas disponibles
  • main : classe principale du greffon, c’est cette classe qui sera instanciée à l'import et qu’on référencera en faisant host.plugins[XXX]
  • handler : s’il vaut "yes", indique que le greffon va réagir à des requêtes XML particulières, toute autre valeur indique le contraire. Nous reparlerons des handlers plus tard
  • description: texte décrivant ce que fait le greffon. Vous remarquerez la présence du _() qui est utilisé pour la traduction (gettext)

Pour notre greffon que nous allons mettre dans un fichier plugin_misc_salut_le_monde.py placé dans src/plugins, nous allons utiliser le code suivant :

#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from sat.core.constants import Const as C
from sat.core.i18n import _
from sat.core.log import getLogger
log = getLogger(__name__)

PLUGIN_INFO = {
    "name": u"Salut le monde",
    "import_name": "SALUT_MONDE",
    "type": C.PLUG_TYPE_MISC,
    "main": "Salut",
    "handler": "no",
    "description": _(u"""Plugin to learn basic concepts of SàT""")
}


class Salut(object):

    def __init__(self, host):
        log.info(_(u"Salut à Toi le monde !"))

C'est à peu près le greffon le plus simple que vous puissiez faire. En lançant SàT, vous devriez voir quelque chose similaire à ceci dans les logs :

2016-07-05 19:15:31+0200 [-] [sat.core.sat_main] importing plugin: Salut le monde
2016-07-05 19:15:31+0200 [-] [sat.plugins.plugin_misc_salut_le_monde] Salut à Toi le monde !

XMLUI

Bon tout ça c’est bien gentil, mais il serait quand même sympa d’avoir notre message sur les frontaux.

Comme vous le savez, SàT est multi-frontaux, autrement dit un message peut être affiché sur Libervia (interface web), sur Primitivus (interface console), (bientôt) sur Cagou (interface bureau/appareils portatifs) ou encore dans Emacs avec l’interface « Sententia ».
Tous ces frontaux affichent les informations différemment : qui avec du texte directement, qui en HTML, qui via un cadriciel graphique, etc. Il serait ennuyant de devoir refaire l’affichage de l’interface pour chaque frontal, aussi nous avons créé un mini langage XML qui permet de décrire une interface de manière générique : XMLUI.
C’est un langage descriptif simple et qui reste volontairement de haut niveau pour que le frontal affiche l’information comme il l’entend. On décrit des choses comme des textes, des JID, ou des listes.

XMLUI contient 2 classes « mères » principales : un widget (texte ou mot de passe par exemple), et un « container » (conteneur) qui dispose les widgets d’une certaine façon (verticalement, 2 par 2, en liste, etc). Vous pouvez lire le code gérant cela dans tools.xml_tools.

La création d’une interface se veut assez simple, et xml_tools contient des méthodes pour aider. Par exemple, l’interface suivante utilisée dans l'UI standard pour le gestionnaire de profils (dans stdui.ui_profile_manager) permet de demander un mot de passe si nécessaire :

form_ui = xml_tools.XMLUI("form", title=D_('Profile password for {}').format(profile), submit_id='')
form_ui.addPassword('profile_password', value='')
d = xml_tools.deferredUI(self.host, form_ui, chained=True)
d.addCallback(self._authenticateProfile, profile)
return {'xmlui': form_ui.toXml()}

Rien de bien compliqué. Quelques remarques sur ce code :

  • on utilise D_ pour le titre, car il peut être traduit différemment d’un profil à l’autre
  • une UI XML peut être soumise (c.-à-d. un résultat est envoyé par le frontal au backend, le mot de passe par exemple), et la méthode appelée dans le backend retourne un dictionnaire. Si celui-ci est vide, le dialogue est fini, s’il retourne une nouvelle interface avec la clef « xmlui », celle-ci sera affichée.
  • pour soumettre une interface on peut soit enregistrer une callback via host.registerCallback (l’identifiant retourné sera utilisé avec submit_id au moment de la création de l'UI), soit utiliser une XMLUI « déferrée » comme ici, ce qui permet d’utiliser le mécanisme de Deferred de Twisted, submit_id doit dans ce cas être une chaîne vide.

Pour notre greffon de test, nous n’avons pas besoin de quelque chose nécessitant une réponse, nous pouvons utiliser la méthode xml_tools.note qui facilite les choses.

Pour utiliser une XMLUI, il y a plusieurs méthodes : création d’une callback via un menu par exemple, ou envoi d’un signal aux frontaux pour leur indiquer qu’il faut afficher l’interface, c’est ce que nous allons faire ici avec la méthode host.actionNew :

host.actionNew({"xmlui": xml_tools.note(u"Salut à Toi le monde !").toXml()}, profile=profile)

Remarquez le toXml() nécessaire pour convertir l'UI XML en texte utilisable à travers le bridge.

Nous avons presque notre greffon qui affiche un message, mais il y a encore un problème à régler : le greffon est importé au chargement du backend, un moment où les frontaux ne sont pas encore actifs, aussi nous ne pouvons pas afficher le message dans l'__init__, il serait envoyé dans le vide.

La solution est simple : nous allons afficher le message quand le profil est connecté. Dans ce cas, la méthode profileConnected, si elle existe, est appelé pour chaque greffon, avec pour seul argument le nom de profil.

Notre code devient donc :

#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from sat.core.constants import Const as C
from sat.core.i18n import _
from sat.core.log import getLogger
log = getLogger(__name__)
from sat.tools import xml_tools

PLUGIN_INFO = {
    "name": u"Salut le monde",
    "import_name": "SALUT_MONDE",
    "type": C.PLUG_TYPE_MISC,
    "main": "Salut",
    "handler": "no",
    "description": _(u"""Plugin to learn basic concepts of SàT""")
}


class Salut(object):

    def __init__(self, host):
        self.host = host
        log.info(_(u"Salut à Toi le monde !"))

    def profileConnected(self, profile):
        msg = u"Salut à vous {} et le monde !".format(profile)
        self.host.actionNew({"xmlui": xml_tools.note(msg).toXml()}, profile=profile)

En lançant Primitivus, voici ce que l’on voit :

résultat avec Primitivus

…et avec Libervia :

résultat avec Libervia

Vous aurez un message équivalent sur les autres frontaux.

À savoir également

Nous n’irons pas plus loin pour ce premier guide afin de ne pas être trop indigeste, mais il peut être utile d’expliquer succinctement d’autre éléments :

  • il y a des paramètres que vous pouvez utiliser pour configurer votre greffon. Ils sont déclarés en XML, et il existe 2 types : « general » pour un paramètre global du backend (par exemple le port d’un serveur), et « individual » pour les paramètres qui changent avec les profils, ce qui est le cas le plus courant (par exemple le JID est un paramètre individuel).

  • il y a un mécanisme de menus qui permettent d’associer une action (souvent un XMLUI) à un menu. Il y a plusieurs types de menus (regardez les constantes C.MENU_*) : C.MENU_GLOBAL sera le menu principal, tandis que C.MENU_JID_CONTEXT sera utilisé en cliquant sur un jid (un contact par exemple).

  • si votre greffon gère une tâche longue quelconque (par exemple un transfert de fichier), il y a un mécanisme pour gérer les progressions, regardez les méthodes progress* pour avoir une idée de leur fonctionnement

  • autre notion importante : la limite de sécurité. Il s’agit d’un simple entier qui indique si une méthode peut être utilisée en environnement restreint ou pas. Pour un frontal utilisé par un simple utilisateur ça n’est a priori pas utilisé, mais un frontal multi-utilisateur comme Libervia, ça permet de limiter ce qui peut être changé (le port d’un serveur ne doit pas être changé tandis que la syntaxe favorite peut l’être par exemple). Vous trouverez des explications sur le wiki.

  • si votre greffon réagit au XML qui passe (ce qui est probablement — mais pas forcément — le cas si vous implémentez une XEP), il agit en « handler » et doit déclarer « "handler": "yes" » dans PLUGIN_INFO. Au moment de l'import, la méthode getHandler sera appelée et elle doit retourner l'instance à utiliser. Pour gérer « disco », votre classe doit implémenter wokkel.disco.IDisco et les méthodes getDiscoInfo et getDiscoItems, référez-vous au code des différents greffons pour bien comprendre.

  • enfin les triggers permettent de modifier le comportement de SàT (du cœur ou d’un plugin), ce sont des méthodes qui sont appelées à certains endroits (d’autres projets parlent parfois de « hook »). Ils peuvent être utilisés par exemple pour modifier un message (le greffon OTR les utilise pour chiffrer le contenu). Il ne faut les utiliser que si nécessaire, car ils compliquent un peu la lecture du code.

Et bien entendu, vous pouvez toujours venir chercher de l’aide sur le salon MUC de SàT : sat@chat.jabberfr.org.

À vos claviers ! Et n’oubliez pas de nous faire signe si vous vous lancez dans quelque chose :)

P.-S. : les morceaux de codes ne sont pas mis en couleurs à l’heure actuelle, j’envisage de faire un greffon pour intégrer pygments, mais pour le moment la priorité est le développement de Cagou.

De la place de la langue dans nos communications

Une des belles choses qu’Internet a apporté — ou tenté d’apporter parce que certains y mettent des barrières virtuelles [1] — est la relative abolition des frontières. Il est devenu facile de communiquer avec des gens de tous pays ou presque, de partager des œuvres, de s’informer, ou encore de travailler ensemble à des milliers de kilomètres de distance. Le moyen de communication le plus utilisé est sans aucun doute l’écrit.

Quand on écrit quelque chose et qu’on le diffuse sur Internet, que ce soit un article sur un blog, de la documentation pour un logiciel, une information à communiquer, ou tout autre document public, on souhaite souvent que sa diffusion soit la plus large possible. Or à notre époque si on veut être lu, il faut adopter la culture de l’internet, publier sur les sites/réseaux en vue de l’internet et utiliser la langue de l’internet.

— la langue de l’internet ? Quelle langue de l’internet ?

— l’anglais bien sûr ! si tu veux être lu, point de salut, c’est l’anglais ou l’indifférence

— mais ceux qui ne parlent pas anglais ?

— pas anglais ? Allons allons, un peu de sérieux, tout le monde parle anglais de nos jours !

Oserais-je avancer le contraire ? Après tout il y a une commodité certaine à utiliser une langue commune, voire n’ayons pas peur des mots, universelle. Pourquoi s’embêter à traduire les choses, à rédiger plusieurs fois, à prendre du temps quand tout doit aller tellement vite ?

Eh bien osons ! Non tout le monde ne parle pas anglais, et osons même plus : il y a énormément de gens qui ne le parlent pas, ou très mal. Oui bien sûr il y a ce couple d’une autre époque, trop vieux pour avoir appris, et cet autre là, plus jeune, mais issu d’un lieu et d’un temps où l’anglais n’était pas bien vu. Ah mais attendez ! Il y aussi ce jeune là, qui n’a jamais trop bougé de sa campagne, et cet autre là qui vient d’un pays où il est peu courant de le parler, celui-là qui vient pourtant d’une grande capitale d’Europe (ce n’est pas la langue de l’Europe ?), et cet autre encore…

Même pour ceux qui le parlent, pour ceux-là, tout n’est pas si simple. Oui bien sûr il y a les « natifs », ceux dont c’est la langue maternelle, et puis il y a ceux qui ont eu les moyens de voyager, la chance d’avoir une éducation ou qui sont simplement doués pour ça. Mais même de ceux-là, combien sont capables de s’exprimer avec autant d’aisance, avec autant de nuances que dans leur langue maternelle ?

Oh, et bien entendu je fais l’impasse sur la culture que la langue véhicule, sur l’influence exacerbée des auteurs anglophones, et sur l’isolation des autres.

Accepter la domination de quelques langues ce n’est pas seulement refuser l’accessibilité ; c’est tuer la diversité et avant tout formater notre façon de penser.

Parlons maintenant un peu plus technique

Quand on écrit un message dans un système de discussion, il est possible de l'« étiqueter » avec des informations (les métadonnées) et en particulier de préciser la langue dans lequel il est rédigé. Cette information est disponible naturellement avec le protocole XMPP, et il est même prévu d’envoyer un message en plusieurs langues simultanément.

Cette propriété est à mon sens essentielle et complètement sous-exploitée dans les logiciels actuels. Pourtant, elle peut être extrêmement utile : un salon de discussion peut être multilingue (les gens n’ayant que les messages dans une langue qu’ils comprennent), un système de conversation (contact d’association, support technique, demande quelconque) peut être dirigé directement vers une personne parlant la langue idoine, une traduction peut être demandée pour un message important, un programme électronique (ou « bot ») peut envoyer des messages dans plusieurs langues à la fois, les règles typographiques peuvent être adaptées, etc.

Ces informations sont désormais utilisées dans « Salut à Toi ». Un greffon expérimental permet même de détecter la langue utilisée automatiquement [2] si celle-ci n’est pas explicitement spécifiée ; ainsi dans un salon multilingue, il est possible de passer du français à l’anglais sans devoir le préciser manuellement à chaque fois.

Ci-dessous une petite animation de la détection d’un texte en plusieurs langues, puis de l’utilisation d’un filtre pour n’afficher que l’une d’entre elles.

filtrage par langue dans Primitivus

Ce n’est qu’un premier pas, il y a beaucoup de choses envisageables pour permettre aux gens de s’exprimer dans la langue qu’ils maîtrisent le mieux, et bien sûr en dehors de la messagerie instantanée également (pour le blog par exemple).

Ah, et puisque vous le demandez, non SàT n’utilisera pas de drapeaux pour les langues, ceux souvent utilisés à cette fin étant des symboles de pays et non de langues.


[1]grand « firewall » de Chine, vidéo ou autre visible uniquement depuis certains pays, blocage de sites, etc

[2]greffon basé sur langid.py, les résultats sont corrects mais pas parfaits, il y a toutefois des améliorations envisageables

Presentation of Libervia/Salut à Toi at Linuxwochen (Wien)

Hello,

a short message to give you the link to our talk explaining Salut à Toi and Libervia at Linuxwochen in Vienna (Austria), 2 weeks ago.
The talk is in english, and we do a live demo of an installation with docker images, and publishing to the blog graphically with Libervia or directly in console with Vim. Thanks to the Linuxwochen team for inviting us and organising this nice event!

Talking about Vim, a new Emacs frontend has been started by Xavier Maillard (screenshot below), so nobody is jealous ;)

We have also started working on Cagou, our new desktop/mobile device frontend.

For more details, you can come to talk in our room: sat@chat.jabberfr.org.

First image of Sententia, the new Emacs frontend:

first image of Sententia

Mourir ? Plutôt crever ! :(

C'est rare que je sois touché par la disparition d'une célébrité, mais j'aimais beaucoup Siné même si je n'étais pas toujours d'accord avec lui. C'est un des derniers représentants d'une génération qui s'en va, et c'est bien triste.

Pour ceux qui ne le connaissent pas, le documentaire « Mourir ? Plutôt crever ! » est vraiment pas mal, et il n'est pas rare de croiser ses dessins un peu partout, que ce soit dans la presse ou dans des bars (y compris en dehors de la France, j'en ai déjà vu à Vienne en Autriche par exemple). Son histoire est chargée, le documentaire cité raconte des choses comme sa rencontre avec Malcom X ou comment la police chinoise l'a intérrogé sur son dessin de chat disant « Mao ».

Ses chroniques du mercredi vont me manquer.

SàT: quelques nouvelles en vrac

Salut à vous,

j'ai assez peu de temps devant moi, alors je vais faire bref pour les quelques nouvelles sur notre avancement.

Déjà je voulais annoncer que nous ne sommes plus à plein temps sur SàT, Souliane et moi avons repris un travail salarié. Le rythme de développement s'en retrouve bien sûr réduit, mais reste relativement soutenu.

Le développement sur Cagou, notre prochaine interface bureau/appareils portables promise suite à notre financement participatif, est d'ailleurs en cours, il est possible de se connecter depuis, et il y a une gestion basique des widgets.

Voici une petite vidéo avec les premières images. La gestion des widgets est inspirée de l'excellente interface de Blender : l'idée est d'avoir à la base un seul widget que l'on peut changer en cliquant sur une icône (un widget pouvant être une conversation, un fil de blogs, des fichiers en partage, la liste de contacts, etc), et de pouvoir séparer l'écran en faisant glisser une barre. Ne faites pas attention à l’aspect graphique qui va changer (j'ai pris une barre du thème par défaut de Kivy pour le développement, mais ça va changer par la suite).

Mais ça n'est pas tout ! Un autre frontal est en cours de développement, destiné à Emacs le bien connu système d'expl éditeur de texte. Il répond au doux nom de « Sententia », et c'est Xavier Maillard qui s'est lancé dedans, et vous pouvez suivre son avancement (ou lui filer un coup de pouce *clin d'œil* *clin d'œil*) sur http://git.maillard.im/xma/sententia.
Une petite mise en appétit :

Première image de sententia

Il y a pas mal de développements en cours, mais je commence à fatiguer, alors je détaillerai une autre fois.

Enfin, pour ceux qui sont dans cette zone, nous serons Souliane et moi à la « Linuxwochen » ce samedi à Vienne (Autriche) pour présenter SàT : https://cfp.linuxwochen.at/de/LWW16/public/events/398.

À bientôt !

Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite)

pour lire les épisodes précédents, suivez l'étiquette correspondante

Maintenant que nous avons vu la copie de fichiers « classique » et ses défauts, abordons une technologie qui a fait beaucoup parler d'elle — et à raison — quand elle est arrivée : Jingle.

Pour la petite histoire, Jingle est une technologie qui résulte d'un effort commun entre des membres de la XSF et une équipe chez Google qui travaillait sur un protocole de voix sur IP (VoIP). La page Wikipédia retrace succinctement l'historique. La technologie Web « WebRTC » hérite et s'inspire de ce travail.

Jingle est souvent considéré à tort comme une technologie dédiée à la visioconférence. En réalité, c'est une technologie qui permet d'établir une session Pair à Pair (P2P) et de la contrôler de manière très souple. Elle a bien été pensée à l'origine pour la visioconférence, et la XEP-0167 s'appuie dessus à cet effet, mais toute application utilisant des connexions directes (et il y en a beaucoup !) peuvent profiter de Jingle : travail collaboratif, tableau blanc, jeux, chiffrement de bout en bout (en évitant ainsi le serveur), partage d'écran, etc. Nous allons nous intéresser plus particulièrement à une de ces applications : le transfert de fichiers.

Jingle fait une séparation claire entre l'application (ici le transfert de fichier), les transports (nous allons retrouver les connexions « in-band » et « SOCKS5 » mentionnées dans le dernier article), et la gestion de session.
Les applications et les transports sont décrits dans des extensions à part : la copie de fichiers est décrite dans la XEP-0234 « Jingle File Transfert ». Vous noterez qu'elle est toujours au statut « d'expérimental » : étant une pièce majeure du futur de XMPP, le travail est long pour obtenir quelque chose de solide et souple. Pour les transports, nous allons donc réutiliser les XEP-0047 et XEP-0065 décrites dans le dernier article, mais en utilisant respectivement les XEP-0261 et XEP-0260 pour les adapter à Jingle. Il faut donc utiliser pas moins de 6 XEPs pour la copie de fichiers avec Jingle (2 d'entre elles servant à la réutilisation d'anciennes), et il est probable que d'autres viennent étendre les possibilités par la suite, en particulier des nouveaux transports (*). Cela peut sembler un peu compliqué, mais c'est ce qui permet la souplesse de Jingle.

Il est possible de modifier ou remplacer à tout moment un transport ou une application, et c'est là la grande force du protocole. Une vidéo passe mal à cause d'une connexion trop faiblarde ? On change l'application pour avoir une vidéo en qualité dégradée. Une connexion SOCKS5 est impossible à établir ? On remplace le transport par un transport « in-band ». Ce dernier cas appelé « plan de secours » (fallback en anglais) était un des problèmes mentionné dans le dernier article, l'ancienne méthode n'indiquant pas comment changer de transport.

Voyons maintenant le fonctionnement. Encore une fois je ne vais pas entrer trop dans les détails, vous pouvez lire la XEP si vous souhaitez les connaître.

Une session Jingle se décide et contrôle à travers le flux XML de XMPP, pour établir une connexion P2P le plus souvent externe (c.-à-d. en dehors du flux XMPP). Une session propose des contenus (« contents »). Un contenu est composé d'une application (transfert de fichier, Vidéo via RTP, etc) et d'un transport (« in-band », « SOCKS5 », « ICE-UDP », etc). L'intérêt principal d'avoir plusieurs contenus est qu'ils sont liés dans la session : par exemple pour une visioconférence, un contenu peut s'occuper de la vidéo, et un autre de l'audio. Si un contenu dans le même logiciel mais non directement lié à la session est utilisé (par exemple un fichier est envoyé au cours de la conversation), on préférera créer une nouvelle session Jingle en parallèle plutôt qu'ajouter un contenu.

Au moment de la création de la session, nous avons 2 entités qui communiquent : l'initiateur (« initiator ») et le destinataire (« responder »). L'initiateur propose des paramètres et/ou une information pour l'application (par exemple des « codecs » pour une vidéo, ou des informations sur le fichier à transférer) ainsi que pour le transport (pour SOCKS5 les candidats par exemple). Si le destinataire accepte la session, il négocie les paramètres en retour pour l'application (par exemple les codecs proposés qu'il connaît) ou le transport (il indique ses propres candidats dans le cas de SOCKS5).

Quand la session est acceptée, elle est considérée « active », mais il n'est pas encore possible d'échanger des données pour autant : il faut d'abord terminer la négociation et accepter un transport (dans le cas de SOCKS5 ça signifie trouver le meilleur candidat, ou changer de transport, probablement pour « in-band »). Une fois tout en place on peut échanger les données, et éventuellement faire des changements en cours d'utilisation comme expliqué plus haut, ou donner des informations (par exemple indiquer qu'un correspondant a coupé le son (« mute »), ou qu'une sonnerie est en cours). Selon les applications, des cas plus compliqués peuvent apparaître, comme changer le sens de transmission de données, rediriger une session (d'un appareil vers un autre par exemple), etc.

Un autre point important avec Jingle, c'est qu'il est possible de demander une pré-condition de sécurité dans une session, par exemple on peut exiger qu'une session soit chiffrée de bout en bout.

Voici une petite liste non exhaustive des améliorations apportées par Jingle rien que pour le transfert de fichiers :

  • une vraie méthode de secours (« fallback »)
  • les XEP-0260 et XEP-261 adaptent les XEP-0065 et XEP-0047 en tirant vraiment profit de Jingle. Ainsi la XEP-0260 permet au destinataire de fournir ses propres candidats, s'inspirant d'une extension jamais standardisée de l'ancienne méthode (appelée « fast-mode »). C'est une grosse avancée, car dans l'ancienne méthode le destinataire doit accepter (et réussir à joindre) les candidats de l'initiateur sinon la connexion échoue. L'échec peut arriver dans de nombreux cas, et si l'initiateur n'a pas de proxy, mais le destinataire en a un, celui du destinataire ne peut pas être utilisé.
    Dans la méthode utilisée avec Jingle, le destinataire peut proposer son proxy, ou la connexion peut s'établir si l'initiateur est injoignable (derrière un NAT par exemple), mais pas le destinataire. L'échec est beaucoup plus rare
  • il est possible de fournir la somme de contrôle (« hash ») quand on le souhaite, et ainsi la calculer au fur et à mesure. Avec l'ancienne méthode c'est tout au début ou rien, ce qui risque de provoquer un ralentissement avant le transfert s'il faut faire le calcul pour un gros fichier
  • avec la XEP-0234, l'initiateur peut demander un fichier au destinataire, au lieu d'uniquement pouvoir lui en proposer un
  • la XEP-0234 permet aussi l'ajout de fichiers en cours de session
  • le chiffrement de bout en bout est possible et prévu, bien que non encore standardisé
  • « ICE-TCP » est en cours de standardisation et devrait arriver cette année (*), permettant de mieux traverser les NATs

Au final, il est quasiment impossible d'échouer un transfert de fichier via Jingle. Le principal cas que je vois est si un des serveurs a une politique interdisant un tel transfert. Cependant, la solution de secours via le flux XMPP « in-band » est gourmande en ressources et très lente, c'est pourquoi il y a du travail sur de nouveaux transports comme ICE-TCP. Ces nouveaux transports serviront à toute application basée sur Jingle : réutiliser l'existant est un des gros points forts de Jingle, et de XMPP en général.

Jingle est une excellente technologie, avec un gros potentiel. Avec PubSub, c'est probablement un des gros piliers du XMPP de demain.

J'en profite pour rappeler que ce blog vient de passer de Dotclear à Salut à Toi, autrement dit il est désormais entièrement basé sur XMPP. J'ai publié une petite série d'articles expliquant la mise en place d'un blog XMPP avec Libervia, son intégration dans une configuration Apache, l'import d'un blog Dotclear et enfin la publication de billets : à lire par ici.

Pour le prochain article, je ne suis pas décidé. Il est possible que je parle de chiffrement de bout en bout vu que c'est un domaine qui bouge en ce moment, ou que je continue sur la lancée Jingle avec les dépôts de fichiers. Cependant j'ai de moins en moins de temps libre, et je préfère consacrer le peu disponible au développement de SàT, le développement de la version bureau/mobiles promise en fin d'année dernière ayant commencé.

(*) cet article ayant été rédigé il y a plusieurs semaines, entre temps la XEP en question est sortie : XEP-0371

Powered by Salut à Toi
Subscribe to this news feed Atom feed