La plate‐forme MongooseIM est disponible en version 2.0.0

Posté par  (site web personnel) . Édité par Davy Defaud, palm123, Nils Ratusznik, Benoît Sibaud, BAud, Florent Zara et M5oul. Modéré par Nils Ratusznik. Licence CC By‑SA.
41
12
déc.
2016
XMPP

La plate‐forme MongooseIM est disponible en version 2.0.0 ! Pour information ou rappel, c’est une plate‐forme de messagerie mobile instantanée, massivement extensible, dont le cœur est basé sur XMPP (Jabber). Elle permet de bâtir des applications de clavardage, ou de simplement déployer la partie serveur pour une communauté, association, entreprise ou administration, en utilisant des clients XMPP/Jabber standards. Cette version 2.0.0 est une étape majeure dans le développement de MongooseIM, les nouveautés sont spécialement conçues et contribuées pour les développeurs (backend, iOS et Android), également les administrateurs systèmes et devops.

MongooseIM platform

Survol des nouveautés, détaillées en seconde partie :

  • pivot : d’un serveur isolé vers une plate‐forme complète client‐serveur ;
  • PubSub, ou « publish‐and‐subscribe » ;
  • MUC light, la discussion de groupe simplifiée ;
  • une API REST pour les clients et pour les serveurs ;
  • contributions significatives aux bibliothèques XMPP/Jabber :
  • documentation revue et augmentée ;
  • des tests fonctionnels et performance en continu.

Powered by XMPP

Sommaire

Les mangoustes de MongooseIM

Les nouveautés en détail

Pivot : d’un serveur isolé vers une plate‐forme homogène et cohérente

Ceci va grandement faciliter la vie des développeurs et intégrateurs. Avant, le serveur XMPP/Jabber MongooseIM était livré tout seul. Pour l’intégrer, il fallait chercher les composants logiciels serveur ou client qui avaient les mêmes fonctionnalités. Et l’on en trouvait, mais la disponibilité de ces fonctionnalités était relativement inégale sur l’ensemble des composants. Donc, il fallait coder+contribuer la fonctionnalité manquante sur les composants pour lesquels celle‐ci manquait. Et pour nos clients c’était très rageant ! Cela faisait perdre beaucoup de temps et cela donnait une mauvaise image de XMPP/Jabber : le paysage était ressenti comme incohérent, voire obsolète, en tout cas frustrant.

Depuis le début de l’année 2016, nous contribuons activement aux bibliothèques client Smack pour Android et XMPPFramework pour iOS : nous codons les mêmes fonctionnalités que celles existant sur le serveur MongooseIM. Donc, une fonctionnalité prise en charge côté serveur existe dorénavant côté bibliothèque client. Bien sûr, nous avons testé et validé l’interopérabilité, en codant de vrais clients. Ceci retire une belle épine du pied des développeurs, sauvant beaucoup de temps de codage, intégration et test. L’ensemble des composants que nous codons et auxquels contribuons est donc maintenant complètement cohérent et homogène (en plus d’être libre et à code ouvert), plus de questions à se poser, tout va beaucoup plus vite.

Les composants de la plate‐forme MongooseIM

Voici les composants de la « plate‐forme » :

  • le serveur XMPP/Jabber MongooseIM est développé en Erlang sous licence GPL v2 par Erlang Solutions ;
  • les bibliothèques sont :
    • pour la partie XMPP/Jabber, nous contribuons activement à ces deux projets majeurs : XMPPFramework en Objective-C pour iOS, sous licence BSD, et Smack de la communauté igniterealtime (développant également le célèbre et très facile Openfire) en Java pour Android, sous licence Apache 2.0,
    • pour la partie API REST : Jayme d’Inaka pour iOS en Swift, sous licence Apache 2.0, et Retrofit de Square en Java pour Android, sous licence Apache 2.0 ;
  • escalus, le client XMPP/Jabber en Erlang sous licence Apache 2.0, par Erlang Solutions ;
  • amoc, l’outil de test de charge en Erlang sous licence Apache 2.0 par Erlang Solutions ;
  • WombatOAM, l’outil d’opérations et de maintenance des systèmes Erlang et Elixir (propriétaire) par Erlang Solutions.

Bientôt, peut‐être, si nous recevons de la demande :

  • Icicle, un serveur ICE, standard ouvert de l’IETF, pour la traversée des NAT et le relai de flux média (STUN + TURN) : en gros, MongooseIM avec le client peut déjà faire le signalling c’est‐à‐dire la négociation de l’appel (faire sonner, décrocher, raccrocher) ; ensuite, les clients peuvent faire de la voix et/ou vidéo en P2P, ou pair à pair, mais lorsqu’il y a des NAT, cela se complique énormément et un serveur ICE est la solution pour faire transiter la voix et la vidéo ;
  • Platypus, serveur de notifications (vers APNS et GCM), basé sur le standard ouvert XEP-0357 : Push Notifications, donc déjà disponible dans les bibliothèques client conseillées ;
  • Mangosta, des clients mobiles libres pour iOS et Android, orientés « chat » et social, très modernes en termes de fonctionnalités, mais très peu aboutis en termes d’interface utilisateur ; les clients Mangosta ne sont à ce stade que des démonstrations technologiques, offrant une « expérience utilisateur » pas encore soignée ;
  • Tide, un environnement de tests de charge en continu, que l’on a montré au POSS (Paris Open Source Summit) 2016.

En résumé, la plate‐forme MongooseIM est cohérente et homogène, donc vous sauvera énormément de temps d’intégration. Elle continuera de s’étendre en fonction de vos besoins.

PubSub ou Publish‐and‐Subscribe : du social en temps réel

Les « innovateurs » vont bondir de joie ! Un des problèmes des protocoles et autres « solutions » de messagerie instantanée, c’est que tout est (trop) centré sur le message instantané (et la présence), il n’existe que peu de place pour d’autres types d’interactions temps réel. Donc peu de possibilité de créer ou « innover » de nouvelles expériences utilisateur.

XMPP PubSub Publish-and-Subscribe

PubSub ou Publish‐and‐Subscribe (peut‐on traduire par « publier et souscrire » ?) est bien connu de tous les développeurs. Il s’agit ici de l’implémentation du PubSub standardisé de XMPP/Jabber : XEP-0060 : Publish‐Subscribe. Vous êtes encouragés à (re)lire au passage l’excellent série Parlons XMPP de Goffi, en particulier Parlons XMPP — épisode 8 — PubSub et PEP. Ce PubSub de XMPP permet, entre autres, d’ajouter des fonctionnalités de réseaux sociaux, comme le font Movim et Salut à Toi (Libervia) et Jappix.

En effet, la tendance est la suivante : le modèle « réseau social avec en fonctionnalité secondaire une messagerie » atteint ses limites (Facebook, Twitter et Instagram) et est un marché complètement saturé. On voit donc émerger le modèle « messagerie instantanée avec réseau social », inversant cette approche. Car la messagerie instantanée est encore et toujours en croissance, dans un contexte ou les applications et leur monétisation sont en ralentissement. Les « chatbots » et « intégrations » sont quelques‐uns des catalyseurs actuels de cette croissance. Nous poussons donc logiquement ce modèle « messagerie instantanée avec réseau social », avec une démonstration technologique sans prétention et en supportant les efforts de Movim.

Movim et le microblogging social sur PubSub
Ici un exemple de publication d’article avec photo, suivi de commentaires, le tout dans un client XMPP sur le Web. Movim utilise PubSub pour cette partie sociale.

MUC light, ou le « group chat » simplifié et optimisé

Ceci est notre contribution pour les utilisateurs, pour une bien meilleure expérience. Le standard MUC ou Multi‐User Chat, le « group chat » ou salon de discussion, souffre de gros défauts de conception. XEP-0045 : Multi‐User Chat a été conçu à la fin des années 90 et au début 2000. À cette époque, la connexion au réseau des réseaux était temporaire, car elle se faisait à travers les modems téléphoniques et précédait l’arrivée massive de connexions fixes permanentes, telles que l’ADSL et le câble, et le smartphone constamment connecté via réseaux mobiles et Wi‐Fi.

Les MUC se reposent donc entièrement sur la présence. Ce qui a pour effet direct ce problème majeur : quand vous perdez votre connexion (tunnel, changement de réseau, mode économie d’énergie, etc.), vous êtes déconnecté du MUC. Ce n’est que lorsque vous pouvez enfin vous reconnecter que vous pouvez (éventuellement automatiquement) rejoindre à nouveau vos salons (ou pas, car c’est une option). Vous « perdez » (vous ne recevez jamais) alors tous les messages échangés dans vos salons durant cette période d’ombre.

Côté serveur, cela génère énormément de présences à diffuser en permanence, consommant de la bande passante à tous les participants. De plus, les utilisateurs reçoivent constamment ces pollutions visuelles de présences « on » et « off » (ce n’est pas toujours une option). Pour finir dans les défauts de MUC, pour les développeurs, la XEP présente de nombreux cas d’usages quasiment jamais implémentés ou pas du tout utilisés par les utilisateurs finals, complexifiant énormément les développements.

Perte de messages, pollution de présence, sur‐complexité : voici les peines dont ne souffrent pas la plupart des messageries modernes du marché du vrai monde de la vie réelle.

Nous avons donc retiré les présences du cœur du group chat (les présence sont de toute façon accessibles individuellement, au niveau du compte, en dehors du contexte d’un group chat). Donc, l’utilisateur souscrit à un salon indépendamment de sa connectivité réseau. Le bénéfice direct est que s’il perd sa connexion, il recevra toujours tous les messages du group chat dans son archive (XEP-0313 : Message Archive Management). Donc, il pourra tout lire après une reconnexion transparente. Ainsi, pas de pertes de messages et pas de bruit de présences non plus.

Nous avons également nettoyé tous les cas d’usages marginaux. La résultante est un group chat ultra simple : MUC light (léger). C’est l’expérience utilisateur que tout le monde attend depuis si longtemps. Côté serveur, nous avons aussi mis la solution dans une grappe de serveurs (cluster), ce qui a pour effet technique de consommer beaucoup moins de bande passante, d’être beaucoup plus tolérant aux pannes et d’être beaucoup plus extensible. Côté client, nous l’avons implémenté, contribué et testé dans Smack pour Android et XMPPFramework pour iOS, prêt au développement client. Vos utilisateurs apprécieront sans aucun doute.

Nous avions contribué les spécifications de MUC light à la XSF début 2015, qui l’a prise en compte fin 2015, sous forme de XEP-0369 : Mediated Information eXchange (MIX). La XSF en est toujours à un stade expérimental, avec très peu d’implémentations permettant l’avancement raisonné de la spécification. MIX n’entre toutefois pas en conflit avec MUC light : MIX servira un très large panel de cas d’usages, alors MUC light est très concentré sur un group chat optimal et simple, facile à développer et à maintenir, avec du code de qualité tournant en très large production actuellement. MUC light est une spécification ouverte.

Journaux de présences sur un MUC fréquenté
Exemple de MUC rempli de présences, sans réelles discussions. Pollutions visuelles au mieux, surconsommation de bande passante au pire. Cette copie d’écran ne montre pas les pertes de messages.

Une API REST pour les clients et pour les serveurs

Une API REST pour tous les développeurs

API REST pour les clients

Ceci devrait faire plaisir à beaucoup de développeurs de clients, qu’ils soient sur mobile ou sur le Web. Un des principaux problèmes est que XMPP et XML perdent du terrain, puisqu’énormément de développeurs se tournent plutôt vers des API REST avec du format JSON. Un autre problème est que la programmation asynchrone est parfois difficile ou incomprise. Il devient par conséquent difficile de trouver des développeurs XMPP.

Nous livrons donc une API REST très simple avec format JSON. Elle va s’étendre avec le temps, selon vos besoins. Avec cette API REST, la barrière d’entrée est abaissée et la courbe d’apprentissage amoindrie. Il vous sera donc plus facile d’embaucher les développeurs qu’il vous faut.

Notez bien : nous conservons le cœur XMPP/Jabber propre à MongooseIM et nous nous engageons publiquement à continuer de supporter les communautés XMPP. Nous n’offrons qu’un nouveau choix d’interface.

Dans notre documentation, nous introduisons donc ce qu’est un JID, ou Jabber ID, ou adresse XMPP, de la forme user@domain (comme une adresse de courriel). Et nous livrons une documentation Swagger, simple et facile à lire, standard de fait.
Doc de l’API REST côté client

API REST pour les serveurs

Une API REST existe aussi pour les développeurs back‐end, les administrateurs système et devops, directeurs techniques et architectes système. Jusqu’à aujourd’hui, il était possible d’utiliser le système de hooks et la ligne de commande pour intégrer MongooseIM dans une infrastructure existante. C’était assez difficile…

Donc, nous avons fourni une API REST API côté serveur et les avantages sont certains : il est beaucoup plus facile de coder et d’intégrer MongooseIM avec les autres composants serveurs.
Documentation de l’API REST côté serveur

Contributions aux bibliothèques mobiles, iOS et Android

Ceci s’adresse aux développeurs sur mobile, iOS et Android. Le problème se situait dans l’incohérence entre des bibliothèques libres tierces pour les clients et le serveur MongooseIM : une fonctionnalité pouvait apparaître sur un composant, mais pas les deux autres. Difficile dans ces conditions d’avancer vite et proprement dans le développement de votre application : besoin de coder, intégrer, tester et contribuer.

Alors, nous avons contribué les fonctionnalités disponibles dans le serveur MongooseIM aux bibliothèques iOS XMFFFramework et Android Smack. Nos contributions se reposent sur de vrais clients qui intègrent respectivement ces deux bibliothèques. Maintenant, il est beaucoup plus rapide de coder une application complète.

XMPP/Jabber

Les contributions portent sur :

API REST

Ces bibliothèques n’ont été qu’intégrées :

Documentation revue et augmentée

Suite à discussions et commentaires avec les communautés et clients, la documentation a reçu beaucoup de soin :

Passez à l’action

Vous souhaitez contribuer, influencer ?

La suite ?

Avez‐vous besoin d’un serveur ICE pour la voix et la vidéo ? Icicle pourrait vous être utile. Vous nécessitez absolument d’un serveur de push notifications ? Platypus peut vous servir. Vous désirez faire tourner des tests de charge en continu ? Tide vous aiderait sans doute. Nous avons besoin de vos avis pour prioriser nos activités.

Nous sommes en cours de développement de clients libres pour Android et iOS. Nous nous orientons vers de la messagerie de troisième génération, donc plus proche des propriétaires Slack, HipChat (ce dernier est basé sur XMPP) et des libres MatterMost et Rocket.Chat, hélas non basés sur XMPP/Jabber.

Pour rappel ou pour information :

  • la première génération était centrée sur la présence et le PC de bureau via connexion par modem. Exemples : ICQ, MSN, AIM, Yahoo! Messenger, Gadu-Gadu, QQ, NateOn. Cette génération est révolue ;
  • la seconde génération était centrée sur les appareils mobiles, proche de l’expérience SMS/MMS. Exemples : WhatsApp, WeChat, LINE, Google Talk / Hangouts, KakaoTalk, Viber. Cette génération va arriver en fin de vie ;
  • la troisième génération est centrée sur le group chat et le multi‐appareil, les intégrations et les chatbots. Exemples : Slack, HipChat, Otalk, Kaiwa, Zulip, Mattermost, Let’s Chat, Rocket.Chat. Cette génération est en pleine explosion.

Aller plus loin

  • # Comparaison avec Prosody ?

    Posté par  (site web personnel) . Évalué à 5.

    Bonjour,
    Merci pour cette présentation très complète et instructive.
    J’utilise actuellement Prosody. Quelles différences y a-t-il entre celui-ci et le composant serveur de Mongoose ? Même public ? Même fonctionnalités ? Ou pas…

    • [^] # Re: Comparaison avec Prosody ?

      Posté par  (site web personnel) . Évalué à 5.

      Je ne suis pas neutre, mais vais tenter de l'être.

      Prosody est codé en Lua, donc très facile et rapide à développer.
      Prosody est très en vogue dans la communauté, car - je pense que c'est la raison principale - il offre de très nombreux modules.

      MongooseIM est codé en Erlang, donc très scalable et tolérant aux pannes.
      MongooseIM se différencie par son approche plateforme (serveur, bibliothèques client, bientôt plus) et sa scalabilité.

      • [^] # Re: Comparaison avec Prosody ?

        Posté par  . Évalué à 5.

        Est-ce que Mongoose offre autant de fonctionnalités?
        Je suppose que la question sous-jacente, c'est si et en quoi Mongoose serveur serait un meilleur choix que Prosody hors entreprise, et hors très grosses structures?

        Le tout intégré est intéressant, mais si on parle de standard, les clients Mongoose ou pas doivent marcher avec les serveurs, Mongoose ou pas. Que gagne-t-on dans l'intégration?

        • [^] # Re: Comparaison avec Prosody ?

          Posté par  (site web personnel) . Évalué à 6.

          Est-ce que Mongoose offre autant de fonctionnalités?

          Non, nous nous sommes concentrés sur l'essentiel, le plus demandé, le plus utile. MongooseIM est moins un terrain d'expérimentation que Prosody (aucune connotation négative intentionnelle).

          Je suppose que la question sous-jacente, c'est si et en quoi Mongoose serveur serait un meilleur choix que Prosody hors entreprise, et hors très grosses structures?

          La robustesse, car le language Erlang possède des fonctionnalités et des qualités inégalées.

          Aussi, nous sommes très appliqués sur le test : unitaire, fonctionnel, intégration, bout en bout, et… load test. Tout cela est opéré en continu. Notre approche "plateforme" ou "intégré" nous permet cela.

          Le tout intégré est intéressant, mais si on parle de standard, les clients Mongoose ou pas doivent marcher avec les serveurs, Mongoose ou pas. Que gagne-t-on dans l'intégration?

          L'indépendance, le choix, l'évitement du « vendor-lock-in », la garantie de continuité de service, la compatibilité, et puis aussi le fait qu'on n'a pas à réfléchir quel composant adopter, et on n'a pas à perdre du temps à (re)coder des fonctionnalités.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.