Un tour d’horizon de XMPP/Jabber, ou « XMPP Roundup », est fait, de manière irrégulo-mensuelloïde (grossièrement tous les mois) sur le blog de la XSF (XMPP Standards Foundation), en anglais, à l’adresse que vous allez bookmarker : http://blog.xmpp.org/. Le feed est dispo à cette adresse http://blog.xmpp.org/index.php/feed/ pour vos agrégateurs, ou mieux, vos bots de notification en temps réel sur XMPP.

Pourquoi je parle ici du Roundup ? C’est pour donner un peu de visibilité à ce billet dans le monde francophone, qui regrette souvent le manque apparent d’actualité Jabber/XMPP, alors que ça ne manque pas du tout, ayant bien du mal à suivre, je vous l’avoue.

Je vous invite à aller lire la dernière édition : XMPP Roundup 12. J’y parle de Psi 0.13 et Pidgin 2.6, logiciels libres qui intègrent tous les deux la VoIP Jingle, mais aussi la synchro de données du navigateur Chrome, des prochains Jingle Nodes qui reprennent le principe de l’encombrant Skype en étendant les concepts, à suivre donc.

Et puis par la même occasion, allez également lire les précédentes éditions, car il y a sans doute des choses que vous avez loupé, sachant que celles qui vous intéressent le plus ne sont pas forcément celles qui font le plus de buzz :

• XMPP Roundup 11 :
  • OneTeam 3.0 for iPhone
  • Pandion passe GPLv3
  • Deux implémentations de Wave : PyGo et ejabberd
  • Collecta le moteur de recherche en quasi temps-réel
  • Juick le réseau social basé sur XMPP
  • SuperFeedr, le super agrégateur
• XMPP Roundup 10 :
  • Google annonce Wave, l’e-mail/wiki/IM à tout faire
  • La bibliothèque exmpp en erlang
  • Et surtout la publication des spécifications Jingle en version 1.0 ou « Draft », encourageant les implémentations
• XMPP Roundup 9 :
  • Mojo, le PubSub par Palm
  • Le Firehose de WordPress.com
  • xBookmarks, l’extension Firefox pour sauver les bookmarks sur XMPP
• XMPP Roundup 8 :
  • Identichat, le MUC personnel pour Identi.ca
  • PEtALS, l’ESB opensource qui utilise XMPP
  • L’annonce Swift, le futur client XMPP multiplateforme
  • Synapse, le client XMPP hautement graphique pour Linux
  • Jabiru, le client XMPP pour Android
  • Omega publie MU-Conference en version 0.8
  • La fondation Apache démarre Vysper, son serveur XMPP
• XMPP Roundup 7 : là, c’est le rapport du FOSDEM de Bruxelles, où ça parle de BOSH, PubSub, Jingle, l’admin et les optimisations mobile, entre autre
• XMPP Roundup 6 :
  • Mats Bengtsson le développeur principal de Coccinella décède
  • QuakeLive utilise XMPP
  • Enomaly utilise XMPP pour la commande et le contrôle décentralisé
  • Le plugin WordPress Jabber Feed par Jehan permettant de corss-poster sur PubSub
• XMPP Roundup 5 :
  • Notre bienaimé Gajim voit son numéro de version incrémenté à 0.12
  • Tigase sort lui en version 4.1
  • BuddyMob le client XMPP social sur Android
  • Ya Online le service XMPP de Yandex (le Goole russe)
  • Prosody le tout nouveau serveur libre en Lua
  • Fire Eagle par Yahoo offrant la géolocalisation sur PubSub
  • Et enfin le publication du livre « XMPP: The Definitive Guide » surnommé XTDG
• Et puis je m’arrête là, car on passe en 2008…

J’en profite pour lancer un appel à commentaire et un appel à contribution :

• Appel à commentaire : j’aimerais connaître votre avis sur « le fonds et la forme », comme on dit, ce qui est bon et ce qu’il y a à améliorer
• Appel à contribution : si vous avez des news, n’hésitez pas me les passer, pour que les intègre au prochain Roundup

À vos claviers, répondez.

La XSF (XMPP Standards Foundation) est l’entité qui gère les spécifications du protocole XMPP : les spécifications seulement, pas les logiciels.

Schématiquement, voici les différents groupes que l’on retrouve dans la fondation :

• Il y a des membres, acceptés par cooptation, en reconnaissance d’un travail effectué dans le monde XMPP.
• Le Council est le conseil technique, celui qui décide de prendre en charge les propositions de XEP (XMPP Extension Protocol), qui les maintient et fini au bout d’un certain temps par en proposer à l’IETF.
• La Board of Directors (ou Conseil d’Administration) assure la direction de la fondation, au niveau légal et business, et en donne les orientations futures.

Certains d’entre vous l’ont peut-être déjà vu passer, je me présente au conseil d’administration ou Board of Directors.

Cette candidature est tout à fait sérieuse, même si je ne me mets pas la pression à ce sujet. Je vous encourage à la lire, bien qu’elle ai été rédigée rapidement.

Je peux apporter à ce CA un peu plus de dynamique, de communication, et d’écoute de la communauté.

J’écris cet article ce matin, pour lancer un appel à la communauté francophone XMPP : je fais appel à toi, cher lecteur, pour te demander ce que la XSF pourrait améliorer. Le but n’est uniquement de consolider ma candidature, mais surtout d’apporter de la matière à réflexion au CA et aux candidats actuels.

La clôture des candidatures étant fixé à… aujourd’hui (11 septembre), je vous propose de commenter cet article, disons avant 18h (je sais, c’est très court, désolé), et je mettrai à jour ma candidature. Les votes auront lieu du 14 au 30… par les membres.

Merci d’avance, à vos claviers…

On dirait bien que certains événements s’enchaînent ces temps-ci. Mais ne nous emballons pas, ne serait-ce que la loi des séries, ou un vrai mouvement de fonds ?

Passons en revue ces événements :

• On avait déjà Jingle voix et vidéo dans Empathy, Jingle voix dans Coccinella, Jingle voix dans Nimbuzz, et dans quelques autres
• Les spécifications Jingle sont finalisées en juin
• Psi 0.13 est sorti avec Jingle voix, toujours en juin (Psi+ également)
• Un serveur STUN atterit dans ejabberd, en août
• Pidgin sort sa version 2.6 avec Jingle voix et vidéo, en août

Comme Pidgin se repose sur la bibliothèque libpurple, réutilisée entre autre par Adium, le client libre et multi-protocole pour Mac OS X, va-t-on voir arriver Jingle voix et vidéo dans Adium les prochains mois ?

Je sais qu’il existe quelques branches Jingle dans certains projets XMPP/Jabber, va-t-on les voir sortir de l’oeuf dans les prochaines mois ?

Quoiqu’il en soit, il faudra s’impliquer dans les tests.

Ensuite, que va-t-il se passer ? Vous avez de la visibilité ?

Juick.com (http://juick.com/) est un réseau social temps-réel. Il possède son avec une interface web bien entendu, mais surtout il est quasiment complètement basé sur XMPP.

Les identifiants sont basés sur votre adresse Jabber (Jabber ID ou JID), à partir de votre client Jabber, vous pouvez envoyer des microblog-posts et commenter en temps-réel. Jusque là, tout comme Laconi.ca (et son installation la plus populaire Identi.ca).

Il fonctionne comme de nombreux services Jabber, avec un bot : un conversation avec celui-ci permet de lui envoyer des commandes.

Mais là où ça va plus loin, le service récupère tout un ensemble de données issues de votre compte XMPP :

• Avatar
• vCard ou carte de viste
• User Tune, la musique que vous écoutez
• User Location, votre géolocalisation
• User Mood, votre {mauvaise|bonne|} humeur
• Vous pouvez encore envoyer des photos par transfert de fichiers (mais attention, seulement IBB, que l’on va nommer l’ancienne méthode) update : on me souffle dans l’oreillette que ça fonctionne aussi sur SOCKS5 – UPDATE de l’update : euh, vi, ça marche

Autres fonctionnalités à ne pas louper :

• tout ou presque se manœuvre à partir de votre client Jabber
• white list et black list
• login par Jabber/XMPP : tapez LOGIN, il vous envoie un lien et vous voilà authentifié sur le web
• tags
• mise en forme par notation wiki : ** pour gras, // pour italique, __ pour souligné
• message persos
• absence
• pas de limite artificielle et inutile à 140 caractères

C’est Anton Ugnich, un ukrainien, qui a tout développé, en Perl et C++.

Voilà enfin le réseau social basé sur Jabber qu’on attendait tous, il s’appelle Juick.

Je n’aurais qu’un jugement sévère à son égard, l’interface web est un peu trop dépouillée à mon goût, ce qui le fait ressembler à du micrblogging…

Mais en réalité, Juick est bien plus que cela. Allez faire un tour dans les Setting et dans l’aide (que vous prendrez le soin de faire traduire par un gentil bot).

Rejoignez moi sur Juick : http://juick.com/Nyco/

Après une longue période d’attente pour certains et de travail pour d’autres , la XSF a publié les spécifications Jingle en version 1.0 (statut ‘Draft’).

Longue attente, car Google avait publié les spécifications de son Jingle-voix en fin 2005, en même temps sa bibliothèque libre libjingle. Rappelons que le Jingle-voix de l’époque est présent dans Google Talk, l’application ‘lourde’, pas web, ni Flash, qui s’installe sur un bureau Windows. Ce qui explique une si longue attente, c’est le travail soigné apporté à la généralisation des spécifications (vidéo, fichiers, ICE), leurs implémentations, le feedback pour maturer les spécifications. Rappelons encore que Jingle est ‘très’ (tout est relatif) attendu, et qu’il est critique d’écrire quelque chose de bien chiadé. Tout cela prend énormément de temps. Un standard ouvert nécessite beaucoup d’attention et de mise au point.

Désolé pour les traductions manquantes, mais je n’ai pas trop le temps, voir le travail de Maclag sur le wiki de JabberFr. Merci Maclag ! Les mises en forme sont de ma main, ainsi que les commentaires.

Voici les spécifications en question :

• XEP-0166: Jingle
  This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat, file transfer) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).
  Il s’agit de la base du ‘protocole Jingle’, permettant un certain nombre d’applications, comme la voix, la vidéo et le transfert de fichiers pour ne citer que les plus évidentes. Pour bien repréciser le contexte, Jingle n’est qu’un protocole d’initialisation de sessions multimédia, qui n’a pas pour but de réinventer la roue (ou l’eau chaude, c’est selon), mais d’utiliser les avantages de XMPP pour apporter le multimédia sur XMPP et/ou d’amener les utilisateurs de XMPP vers le monde SIP (et/ou l’inverse).
• XEP-0167: Jingle RTP Sessions
  This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.
  Là, on a affaire à RTP et UDP, je ne vais pas entrer dans le détail, c’est du protocole réseau de bas niveau.
• XEP-0176: Jingle ICE-UDP Transport Method
  This specification defines a Jingle transport method that results in sending media data using raw datagram associations via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology, which provides robust NAT traversal for media traffic.
  Ici, c’est pour passer les NAT à peu près proprement, de manière standard ouvert. ICE est utilisé également par SIP.
• XEP-0177: Jingle Raw UDP Transport Method
  This specification defines a Jingle transport method that results in sending media data using raw datagram associations via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required.
  On est ici dans un contexte sans NAT, donc beaucoup plus facile, disons plutôt moins difficile.

Il existe également d’autres spécifications encore expérimentales, mais avancées, très probablement Draft après un certain temps d’implémentation et feedback :

• XEP-0181: Jingle DTMF
  This specification defines an XML format for encapsulating Dual Tone Multi-Frequency (DTMF) events in informational messages sent within the context of Jingle audio sessions, e.g. to be used in the context of Interactive Voice Response (IVR) systems. Note well that this format is not to be used in the context of RTP sessions, where native RTP methods are to be used instead.
  Pour passer les sons d’un clavier numérique vers les serveurs interactifs (votre répondeur par exemple).
• XEP-0234: Jingle File Transfer
  This specification defines a Jingle application type for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used.
  Avec cette méthode de transfert de fichiers, on espère se passer des (futures) anciennes méthodes, qui posent toutes un problème dans un contexte particulier. Je vous laisse lire l’intro de cette spec pour mieux comprendre.

Nous avons également d’autres spécifications, encore peu avancées, on ne peut pas encore dire à ce stade ce qu’elles vont devenir à terme (annulées, remplacées par d’autres, etc.) :

• XEP-0247: Jingle XML Streams
  This specification defines a Jingle application type for establishing direct or mediated XML streams between two entities over any streaming transport. This technology thus enables two entities to establish a trusted connection for end-to-end encryption or for bypassing server limits on large volumes of XMPP traffic.
  Utile dans de nombreux contexte : se passer du ou des deux serveurs interdmédiaire, une fois la session initialisée.
• XEP-0251: Jingle Session Transfer
  This specification defines an extension to XMPP Jingle for transferring a session (such as a voice call) from one person to another.
  Pour ‘basculer’ un appel.
• XEP-0260: Jingle SOCKS5 Bytestreams Transport Method
  This specification defines a Jingle transport method that results in sending data via the SOCKS5 Bytestreams (S5B) protocol defined in XEP-0065. Essentially this transport method reuses XEP-0065 semantics for sending the data and defines native Jingle methods for starting and ending an S5B session.
  Pour utiliser les proxies de type SOCKS5.
• XEP-0261: Jingle In-Band Bytestreams Transport
  This specification defines a Jingle transport method that results in sending data via the In-Band Bytestreams (IBB) protocol defined in XEP-0047. Essentially this transport method reuses XEP-0047 semantics for sending the data and defines native Jingle methods for starting and ending an IBB session.
  Pour envoyer tout le flux multimédia dans une session XMPP, peu recommandable afin d’éviter une surcharge du ou des deux serveurs intermédiaires.
• XEP-0262: Use of ZRTP in Jingle RTP Sessions
  This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.
  Pour chiffrer la VoIP.
• XEP-0266: Codecs for Jingle RTP Sessions (de type ‘Informational‘)
  This document describes implementation considerations related to voice and video codecs for use in Jingle RTP sessions.
  J’y reviens en-dessous.
• XEP-0269: Jingle Early Media
  This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.

La XEP-0266: Codecs for Jingle RTP Sessions est très importante puisque les différents implémenteurs pourront utiliser les codecs qui leurs semblent les plus opportuns. C’est très ouvert : les éditeurs proprios pousseront leurs ’solutions’ proprio. Côté audio, c’est Speex et G.711 qui sont poussés, et côté vidéo, c’est Theora, Dirac et H.264. Gageons que les implémentations les plus importantes ou qui auront le plus de succès utiliseront des codecs libres et sans brevets.

Remarquons que SIP est beaucoup mentionné, preuve supplémentaire que XMPP ne réinvente pas SIP, mais cherche l’interopérabilité (j’en remet une couche, désolé).

La publication de ces spécifications n’est pas une fin en soit. C’est juste un passage en version ’stable’, comme un logiciel : ces spécifications contiennent sans aucun doute des bugs mineurs, qui vont être corrigées grâce au feedback des implémenteurs et utilisateurs.

Il s’écoulera encore d’autres années de travail pour que ces spécifications passent dans le girons de l’IETF.

Quoiqu’il en soit, plus rien ne peut retenir les implémenteurs désormais, excepté que le développement d’un logiciel multimédia est bien complexe qu’un client de chat.

J’ai acheté le bouquin « XMPP: The Definitive Guide » en version PDF, sans DRM, à 31,99 $  (je n’ai pas fait la conversion en euros). Il est également disponible à 39,99 $ en version papier (pré-commande à ce jour), ou bien en version papier + électronique à 51,99 $.

Ce bouquin a été écrit par des pointures du monde XMPP :

• Peter Saint-Andre, directeur exécutif et membre du conseil technique de la XSF et (co-)auteur de nombreuses XEP ;
• Kevin Smith, membre du conseil technique de la XSF et ancien chef du projet Psi (pendant 4 ans et demi) ;
• Remko Tronçon, développeur Psi, contributeur de projets liés à XMPP  et auteur de quelques XEP.

Comme d’habitude chez O’Reilly, la couverture affiche un animal qui sort de nulle part, il s’agit là d’un chevrotain (ne m’en demandez pas plus…).

XMPP: The Definitive Guide

Très synthétique et facile à lire (il fait tout de même 310 pages), il y a toujours un peu d’humour au fil de l’eau et un résumé à chaque chapitre. Il touche à tout ou presque, il couvre la plupart des fonctionnalités de Jabber et des XEP d’un point de vue fonctionnel, de la présence et du chat à Jingle, en passant par PubSub, et aussi les formulaires, les commandes, et l’échange de fichiers. Il est très utile aussi bien d’un point de vue d’un utilisateur qui veut en savoir plus (et qui ne lit pas forcément le XML), qu’un développeur pour bien comprendre l’architecture, le fonctionnement de base et les fonctionnalités avancées. Il conviendra même à un prof, chercheur ou manager, ou encore un architecte.

Au chapitre des reproches, je mettrais les copies d’écrans qui sont en noir et blanc et… sous Mac OS X. De même bien qu’il soit bien fournit en exemples de XML, il manque là encore de la colorisation syntaxique pour améliorer la lecture.

Voici le sommaire :

Donc Oracle rachète Sun, le gros buzz du jour.

La grosse question étant : que va-t-il advenir des produits opensource respectifs :

• Sun : Java, MySQL, OpenOffice.org, VirtualBox, OpenSolaris, GlassFish, OpenSPARC, NetBeans, etc.
• Oracle : BerkeleyDB, OCFS, InnoDB, etc.

Un grosse question également est : que va-t-il adevnir des produits XMPP ?

• Sun : Sun Java System Instant Messaging
• Oracle : Oracle Beehive et Oracle Messenger

Ces deux produits ne sont que propriétaires et assez peu répandus à ma connaissance.

Vont-ils être libérés ? Fusionnés ?

« Passe-moi un coup de fil », « Envoie-moi un e-mail » ou bien « Cherche/surfe sur le web » sont des expressions courantes de la vie quotidienne d’un utilisateur du téléphone et d’internet d’aujourd’hui. On dit un internaute en bon français moderne. En revanche, on ne dit pas « téléphonaute », on ne dit pas, c’est normal/logique.

En effet, nul doute qu’il y a un seul réseau de téléphonie ouvert, public, unique et fédéré mondialement, qu’il soit filaire ou mobile, avec des opérateurs partout sur le globe. On appelle ça « téléphone ».

Nul doute également que pour les messages et leurs pièces jointes il y a un seul réseau de messagerie ouvert, public, unique et fédéré mondialement, avec des fournisseurs présents sur tous les continents. On appelle ça « e-mail », ou mail (ou encore mèl, mais bon).

Nul doute encore qu’il y a un seul système d’applications et de publication de documents avec liens hypertextes qui soit standard ouvert, public, unique et fédéré sur internet, avec des fournisseurs dans toutes les régions. On appelle ça « World Wide Web », ou web.

Eh bien, sachez le cas échéant qu’il n’y a nul doute dans le domaine de la messagerie instantanée. Il y a un seul standard ouvert, public, unique et fédéré sur internet.

Mais comment l’appelez-vous ?

• Jabber ? Avec diverses prononciations dont « dja-beur» ou le bon vieux franchouillard « jjja-bère » (avec un vrai « j », pas « dj » à la angliche), ou le fameux mix « dja-bère »
• XMPP ? Avec diverses prononciations dont « ix-ème-pépé » ou le tout nouveau « zimpy »
• Chat ? Avec diverses prononciations dont « tchatte» ou « chatte »
• Tout simplement « messagerie instantanée » ou sa version anglophne « instant messaging » ?
• IM ? Avec diverses prononciations dont« i-ème » ou « aille-ème »
• MI ? Là, une seul prononciation, « ème-i »
• IMP ? Pour « Instant Messaging and Presence », avec « i-ème-pé » ou « aille-ème-pi »
• D’autres usages ?

Il est clair que l’usage de la messagerie instantanée est en forte croissance, et s’installe de manière durable, c’est donc en train d’entrer dans le langage courant, mais par quelle porte ?

La journée de conférences, marquant l’anniversaire des 10 ans de Jabber, au Carrefour Numérique de la Cité des Sciences, s’est bien déroulée. Nous avons eu quelque défections de dernière minute, c’est dommage, mais certaines pour d’heureux événement.

Les conférences se sont succédées toute la journée :

• Jehan Pagès, l’organisateur avec Parinux de l’événement, nous a introduit Jabber/XMPP ;
• Je lui ai succédé sur le sujet « Historique, situation et perspectives », que j’ai posté sur SlideShare, le fichier OpenDocuemtn est disponible en téléchargement (ou visionnable au format Flash) ;
• Laurent Lathieyre d’Ubikod a présenté l’application mobile BuddyMob, qui intègre du chat, du microblogging et de la géolocalisation, le tout sur Android, avec la bibliothèque libre Smack et le serveur XMPP libre ejabberd côté serveur ;
• Jan Torben Heuer est venu de Munster pour nous présenter son projet de réseau social respectant la vie privée, basé sur XMPP et OpenPGP, Diki du Pace Project ;
• Kael nous a présenté son (ro)bot, présentant la météo via les avatar de la carte de visite, de la recherche et programmation d’enregistrement d’émissions de télévision via Freebox et VLC, via découverte de services et commandes ad-hoc, énorme !

Il y avait beaucoup d’auditeurs techniques et libristes dans la salle, tout le monde a été très attentif et motivé, de bonne question posées aux conférenciers. Merci beaucoup Jehan !

À refaire !

Contre la loi  « HADOPI », « Création et Internet » ou encore « riposte graduée » :

http://www.laquadrature.net/HADOPI

On fête les dix ans de Jabber/XMPP, ce samedi, à Paris, on en parle sur L’Agenda du Libre (« Anniversaire décénnal du protocole XMPP ») et sur LinuxFr .org (« Anniversaire décennal de Jabber/XMPP le 28 février »).

En effet, le 4 janvier 1999, Jeremie Miller, l’inventeur de Jabber avait écrit ceci sur Slashdot :

“Jabber is a new project I recently started to create a complete open-source platform for Instant Messaging with transparent communication to other IM systems(ICQ, AIM, etc). Most of the initial design and protocol work is done, as well as a working server and a few test clients.”

C’est au Carrefour Numérique de la Cité des Science que l’on se retrouvera, de 10h à 18h, ce samedi 28 février. La journée permettra de se familisariser avec XMPP, à travers des conférences et des ateliers. L’April, FSF France et Parinux sont les associations organisatrices. J’y présenterai une conférence sur l’historique et l’état des lieux de la messagerie instantanée.

Venez nombreux !

Le mercredi 21 janvier 2009, Simon Chemouil et Geoffroy Youri présenteront XMPP-Jabber lors de la rencontre bi-mensuelle de Toulibre.

Ça se passera au  Centre Culturel Bellegarde,  17 rue Bellegarde à Toulouse, de 19h à 23h.

« La présentation sera filmée et les vidéos seront par la suite mises à disposition sur le site de Toulibre. »

Bravo, belle initiative !

Pour continuer la petite série des serveurs Jabber/XMPP dans les écoles et universités, après l’université de Nantes, l’INSA de Toulouse et Jabber à Centrale Lille, voici le CRANS, Cachan / Réseau @ Normale Sup’.

Mathieu Segaud s’est prêté au jeu.

Peux-tu te présenter brièvement ?

Je m’appelle Mathieu Segaud, je suis l’actuel responsable « de facto », du serveur Jabber de l’association Cr@ns, suis « nounou » (sysadmin) du réseau de l’association depuis maintenant 6 ans et demi. Je suis actuellement en mission longue durée en tant que prestataire chez OneAccess Networks, une startup de 6 ans d’âge, équipementier de France Telecom/Orange, notamment, en leur fournissant la Business LiveBox. Je travaille plus précisément, en tant que mainteneur de plateformes de validation SIP/Asterisk d’équipements µPBX (PABX IP embarqué) et développeur.

Quand et comment as-tu eu l’idée de mettre en place un serveur Jabber au CRANS ?

Personnellement, je ne suis pas la personne qui a déployé en 2003, la première itération de ce service. L’idée est cependant venue de deux raisons bien distinctes ; d’abord, un besoin de messagerie instantanée « sur site » permettant d’assurer un service continu malgré les coupures intempestives et parfois assez régulières de notre FAI (l’ENS Cachan). De plus, l’association a, depuis longtemps, un objet précis qui est la promotion des logiciels libres et Open source, ainsi que celle des standards ouverts. Jabber nous est apparu comme indispensable à cet engagement.

Quelles sont les contraintes ?

Parmi les contraintes lors du premier déploiement, en 2003, les contraintes étaient assez peu nombreuses ; il fallait être attractifs, et pour cela, assurer les services de passerelles vers les différents protocoles de messagerie instantanée de l’époque, principalement AIM/ICQ/Oscar et MSN. À l’époque, c’était ICQ qui était le plus demandé, en tant que protocole le plus utilisé sur le campus universitaire. Parmi les autres contraintes, il y a celles non dictées par la potentielle communauté d’utilisateurs, mais celles dictées par nos sentiments en tant qu’administrateur. On a offert la possibilité de se connecter en sécurisé par SSL (déprécié depuis quelque temps, maintenant).
Le set de contraintes fut beaucoup plus problématique, lors du passage de jabberd1.x à ejabberd ; la raison première était une étude de faisabilité sur l’utilisation des nouvelles XEP et de nouvelles fonctionnalités présentes dans ejabberd. Pour l’instant, aucune ne m’a l’air indispensable, mais les services du type PubSub me semblent pertinents dans un futur déploiement d’Asterisk à la fois en SIP et en Jingle, sur notre réseau.

Comme la plupart des réseaux d’étudiants, notre base d’adhérents est stockée dans un annuaire LDAP. Ejabberd contient un backend d’authentification/accés dans un annuaire LDAP, j’ai donc décidé d’expérimenter la création automatique d’un compte XMPP pour tout adhérent désirant un compte Unix/mail sur nos serveurs, en utilisant LDAP. Ceci a été fait dans l’optique d’« unifier » les adresses mail/XMPP/SIP :

• mailto:regala@crans.org,
• xmpp:regala@crans.org,
• sip:regala@crans.org…

C’était la phase de test à proprement dit. À ce jour, nous avions deux serveurs XMPP déployés, sur deux machines virtuelles Xen, l’un tournant jabberd1.x avec une vieille version du proto XMPP et le vieux jid:jabber.crans.org, l’autre tournant ejabberd sur le jid:crans.org. Suite à divers problèmes techniques que je ne détaillerai pas ici (;)), la VM jabberd1.x s’est retrouvée corrompue et j’ai transféré en hâte le jid:jabber.crans.org sur un vhost d’ejabberd. Cette transition n’était pas voulue, mais elle a permis d’apporter diverses corrections aux fonctionnalités de la première « itération ». Et elle va me permettre d’effectuer les tests des vCard en annuaire LDAP sur une base plus « geek » d’utilisateurs .

Quelle démarche as-tu adopté pour convaincre les décideurs ?

Nul besoin de convaincre à l’époque : les décideurs étaient des libristes déjà convaincus

Quelles solutions techniques ont été choisies et pourquoi ?

À ce jour, on utilise Ejabberd sur une machine virtuelle Xen ; le dom0 en question abrite différentes VM pour différents services annexes offerts aux adhérents.

Une extension de services est-elle prévue ?

Oui, j’aimerais intégrer dans notre annuaire LDAP les vCard des utilisateurs le désirant. Je ne pense pas offrir de support de stockage, nos serveurs offrent déjà cela par le biais d’OpenSSH. À terme, lorsque le software aura rejoint le standard, je désire plugguer Asterisk (PABX OpenSource) pour offrir des services de VoIP soit en SIP, soit en Jingle (XMPP avec vidéo et voix), et utiliser les services de l’un ou de l’autre pour les services de présence.

Comment est publicisé le service dans l’établissement ? Comment est-il perçu ?

Comme la plupart des choses touchant à la vie étudiante sur le Campus et dans l’École, le Crans utilise les news et les documents fournis aux adhérents en début d’année lors de la première connexion, pour montrer ces services. Après, seule une faible fraction d’utilisateurs désirent autre chose qu’internet ou MSN… On organise des install-party qui nous permettent de présenter le logiciel libre et les technologies associées, mais en dehors de ça, il reste très difficile d’intéresser des étudiants ne désirant que conserver son confort habituel de connexion.

Statistiques diverses.

Le serveur est utilisé en permanence par une grosse centaine de personnes, dont la moitié se trouve répartie sur le territoire français, le reste composé d’étudiants actuels de l’École ; cette communauté grandit d’à peu près 20 comptes par an, avec quelques défections (souvent des comptes sur d’autres serveurs, soit pour des raisons de fiabilité, soit pour d’autres raisons ). Le jid:crans.org n’est à ce jour utilisé que par maximum une petite dizaine de comptes, tandis que le jid:jabber.crans.org historique constitue l’essentiel de la charge quotidienne. Depuis l’installation de la machine virtuelle xmpp.crans.org, je n’ai pas pu constater de charge significative dessus de nature à être seulement différentiée du reste de la charge logicielle . À priori cette charge est invisible en tant normal.

Merci Mathieu !

Si vous avez eu vent de telles initiatives dans l’espace francophone, je suis intéressé par votre retour d’expérience.

Afin de bien promouvoir et améliorer la messagerie instantanée libre, ouverte et standard pour tous, il est nécessaire de bien connaître les défauts ostentatoires des messageries instantanées propriétaires.

Merci donc à tous d’avoir voté sur le petit sondage « Ce que vous détestez le plus dans les messageries instantanées proprios et privées ».

Voici les résultats, sachant qu’il y a eu 1325 cases cochées. Le tout est  suivi d’une petit analyse :

En tête de ce que vous jugez être des désagréments :

• le cloisonnement des communautés et leur incommunicabilité : un serveur Jabber sur internet est ouvert et fédéré avec l’ensemble de tous les autres serveurs de la planète ;
• le protocole incompatible avec le reste du monde : XMPP est conçu dans le cadre de l’IETF, l’organisation qui normalise tous les procotoles de l’internet, il est donc interopérable par défaut ;
• le logiciel client officiel obligatoire : la liberté de choix de votre logiciel client est toujours vrai sur Jabber ;
• le flicage intégral de la vie privée des utilisateurs : Jabber n’offre pas un seul serveur central, mais un multitude de serveur décentralisés, de plus un administrateur ou fournisseur de service Jabber n’a que peu de choses à faire de votre activité, ou bien n’a pas assez de trafic pour avoir un ensemble de données significatif à revendre ou utiliser ; et enfin il est possible de chiffrer le trafic client à serveur, mais également de client à client, rendant ainsi vos conversations intégralement privées.

Le plus désagréable dans les messagerie instantanées propriétaires est donc ce qui tourne autour de l’entrave à la liberté. Jabber/XMPP est justement conçu pour la liberté d’utilisation, d’apprentissage et d’extension de la messagerie instantanée.

Utilisez XMPP/Jabber en 2009 et au-delà.

Après un article sur Jabber à l’université de Nantes et une interview de Maxime sur Jabber à l’INSA de Toulouse, voici une interview de vetetix aka Thomas Arnoux, qui a mis en place un service XMPP à l’école Centrale de Lille.

• Peux-tu te présenter brièvement ?

Je m’appelle Thomas, mais je suis en général plus connu sous le pseudonyme « vetetix ». Je suis membre du RézoLéo, le club informatique des élèves de l’École Centrale de Lille.
Avec mon expérience dans cette association, je suis passé du statut d’utilisateur de Windows© et de MSN© ne connaissant rien d’autre à celui de Linuxien et libriste convaincu. Après avoir profité de l’expérience et des connaissances de mes amis pendant plusieurs années, j’essaie désormais de mettre à profit mes propres connaissances. En particulier, j’essaie de promouvoir l’utilisation des différentes technologies basées sur Jabber/XMPP.

• Quand et comment as-tu eu l’idée de mettre en place un serveur Jabber dans l’École Centrale de Lille ?

Je pense que le mieux avant de répondre à cette question est de décrire l’environnement dans lequel évoluent le RézoLéo et les élèves.

La majorité des élèves de l’école habitent dans une résidence privée qui leur est réservée, ce qui nous permet de bénéficier d’une très grande souplesse dans les services informatiques que le RézoLéo offre aux élèves. Nous gérons ainsi l’ensemble du réseau interne, depuis la gestion de l’infrastructure matérielle jusqu’à l’administration des services avancés (portail des élèves, mailing list, etc.), en passant par les outils d’administration du réseau lui-même (DNS, DHCP, etc.). Nous disposons d’une dizaines de serveurs pour y héberger des services, ce qui nous permet de tester, et changer les services facilement.

Mais venons-en à ce qui nous intéresse ici : la mise en place d’un serveur XMPP. Il y a eu, en 15 ans d’existence de la résidence et du RézoLéo, plusieurs générations d’outils de communication en temps réel en interne. Un système basé sur Winpopup était utilisé par plus de 200 personnes (sur les 600 habitants de la résidence) autours de l’an 2000. Ce chiffre a été divisé par deux lors du passage à IRC quelques années plus tard, et diminue d’année en année depuis lors. Maintenant, une vingtaine d’élèves et une vingtaine d’anciens ou d’externes utilisent encore IRC sur son salon principal (#ec-lille@irc.rezosup.net).

Les élèves ne sont en effet plus intéressés par un serveur de discussion en groupe sans valeur ajoutée et relativement geek. Ils obtiennent tout ce qu’il souhaitent en utilisant des réseaux comme MSN© ou Facebook©, que ce soit les discussions en ligne ou d’autres interactions sociales. Devant le constat flagrant que IRC ne permettrait jamais de faire toutes ces choses, je me suis dit lancé dans l’installation d’un serveur XMPP.

• Quels sont les contraintes ?

La contrainte principale était de pouvoir remplir les mêmes rôles que le serveur IRC actuel, c’est à dire être disponible à la fois de l’intérieur et de l’extérieur de la résidence, et d’être utilisable par les anciens élèves n’ayant pas de compte sur le serveur.

L’objectif étant d’offrir un service à forte valeur ajoutée, extrêmement adaptée aux besoins des élèves de l’école, il était nécessaire qu’il s’insère au maximum dans les services existants. Je pense principalement à l’utilisation de l’authentification sur un arbre LDAP, qui est déjà utilisé pour l’authentification sur un wiki interne et sur le portail des élèves. Nous y stockons de nombreuses informations sur les personnes, comme un profil plutôt complet pour le trombinoscope, la liste des clubs et associations dont ils font partie.

Nous pouvons ainsi simplifier la vie des utilisateurs en ayant une gestion centralisée des informations.

• Quelle démarche as-tu adopté pour convaincre les décideurs ?

Il n’y a pas vraiment de décideur, le service sera définitivement adopté s’il convainc de sa supériorité sur son concurrent actuel. Il m’a suffit d’installer un serveur XMPP sur mon propre ordi pour faire des premiers tests, puis ensuite de demander à disposer d’une machine virtuelle dédiée et demander les réglages du réseau pour qu’il remplisse d’emblée la plupart des conditions requises.

• Quelles solutions techniques ont été choisies et pourquoi ?

J’ai rapidement regardé les différents serveurs XMPP existants, en essayant d’en trouver un qui soit assez complet et qui s’améliore avec le temps. Nous disposons de nombreux membres largement assez compétents pour administrer ou installer un serveur un peu complexe, mais n’avons quasiment aucune compétence en développement, il fallait donc choisir un serveur bénéficiant d’un développement actif.

Après avoir testé Jabberd2 et Openfire, mon choix s’est arrêté sur ejabberd, qui offrait de nombreux modules dès l’installation, ainsi qu’un support et une communauté actifs. Jabberd2 (et Jabberd14) ne m’a pas convaincu car il est plus complexe à installer est administrer, et ses composants manquent d’uniformité. Openfire, de son côté, semblait trop intégré, rigide. Du haut de mes faibles connaissances à l’époque, ejabberd me semblait le plus équilibré entre souplesse et puissance.

• Quels services sont offerts à ce jour ?

À l’heure actuelle, nous n’avons pas encore atteint tous nos objectifs, principalement en terme d’intégration avec les services existants. Nous avons tout de même les services de base, avec authentification centralisée par LDAP, module de discussions en groupes (MUC) avec accès aux logs des salons et à deux clients web via un serveur HTTP.

• Quels sont les problèmes que vous rencontrez à l’heure actuelle ?

D’un point de vue technique, nous souffrons de la qualité du réseau. En effet, nous sommes dépendants du réseau à l’extérieur de la résidence (pour rendre le service accessible aux extérieurs). Le réseau est victime de coupures intempestives en journée, et les clients et serveurs XMPP gèrent assez mal le problème. Les participants à un salon de discussion ne sont pas prévenus de leur déconnexion, le salon non plus, ce qui est très gênant. IRC gère le problème des déconnexions (entre les serveurs d’un même réseau) bien mieux, et forcément les ircistes nous le rappellent

Nous sommes aussi dépendants de la gestion des DNS de l’école (notre réseau est lié à celui-ci), nous devons donc nous adapter à ce qu’on nous offre, avec ses qualités et ses défauts (délais de modifications de la configuration, mauvaises configurations malgré des mois de demandes incessantes, etc.). Le principal est tout de même que nous arrivions à contourner les problèmes pour faire fonctionner notre service.

• Une extension de services est-elle prévue ?

Nous continuons activement à faire évoluer le service. Bien évidement, nous travaillons sur l’intégration de la vCard et des « Shared Roster » avec LDAP (nous allons profiter d’une refonte de notre arbre qui va le rendre plus conventionnel, pour ainsi régler les problèmes d’incompatibilité entre ejabberd et notre arbre « fait maison »).

Nous suivons aussi les évolutions des autres serveurs, et nous intégrons les améliorations qu’ils proposent. Je suis ainsi en train d’installer Omnipresence et d’intégrer les informations disponibles dans le trombinoscope. J’essaye de plus de développer un service s’appuyant sur le serveur XMPP pour partager des fichiers de manière privée au sein des associations ou des groupes projets, voire de manière globale à l’intérieur de la résidence. En effet, c’est un des services les plus populaires à l’heure actuelle, il pourrait être intéressant de s’en servir pour promouvoir le serveur XMPP.

• Comment est publicisé le service dans l’école ? Comment est-il perçu ?

La communication se fait via plusieurs moyens. Tout d’abord des affiches placardées dans la résidence et les couloirs de l’école, ensuite des e-mails envoyés de temps en temps à tous les élèves pour leur rappeler l’existence du service et en vanter l’usage dans diverses situations. Pour finir, nous essayons aussi de profiter du bouche à oreille, mais ce n’est pas toujours très efficace.

Il nous faut surtout gérer deux types de communication : celle destinée aux utilisateurs actuels d’IRC, et celle orientée vers les élèves qui n’ont jamais utilisé ce genre de service et qui ne connaissent que Facebook© ou MSN©.

• Possèdes-tu quelques statistiques ? Notamment le nombre d’utilisateurs actifs ?

Je n’ai pas de statistiques exactes, mais on a à peu près une quinzaine de personnes, principalement des membres du RézoLéo, qui utilisent le service régulièrement. C’est très faible comparé aux 600 utilisateurs potentiels, mais on peut facilement relativiser cet « échec » en le comparant à la popularité d’IRC, qui n’a qu’entre 20 et 30 adeptes à la résidence.

Entre les IRCistes qui refusent de faire le changement, et les 550 élèves qui ne connaissent pas le service, on a du mal à le rendre plus utilisé. Je reste tout de même confiant, je fais du lobbying pour qu’on se débarrasse d’IRC et pour que les autres membres du club s’investissent pour améliorer le service. Le jour où on aura entre 50 et 100 utilisateurs actifs à l’intérieur de la résidence je considérerai que le service est une réussite.

• Quelle est la consommation de ressources ?

Je n’en ai absolument aucune idée (je suis un très mauvais administrateur de serveur, et je ne sais pas utiliser la commande « top » ). Plus sérieusement, ejabberd est installé sur un serveur virtuel disposant de 256 Mo de RAM et nous n’avons aucun problème de consommation. Avec seulement une vingtaine d’utilisateurs simultanés, nous n’avons pas besoin de plus.

• Quels sont les points positifs ?

Nous avons de bons retours de la part des nouveaux utilisateurs, qui comparent le vieillissant IRC à ce nouveau service disposant d’avatars, de vCards, de couleurs et d’émoticones. Ce ne sont bien évidemment pas des arguments qui convainquent les IRCistes, qui remarquent plutôt les défauts des clients XMPP.

J’ai aussi, je crois, réussi à montrer aux autres membres qu’il existe des moyens d’enrayer la désertion progressive du service de discussion interne, il faut juste s’en donner les moyens et intégrer les différents services pour créer une forte valeur ajoutée.

• Quels sont les axes d’amélioration ?

Nous avons entre nos mains une bonne base, et le pouvoir de jouer sur tout ce qui est stabilisation, amélioration et ajout des services. Malheureusement, nous ne maîtrisons pas le développement des clients (je m’y suis mis, mais ce n’est pas gagné), donc nous encourageons les développeurs à maintenir leurs efforts. C’est en effet la critique principale qui est faite à Jabber, donc nous espérons que la situation s’améliorera, surtout sous Windows© et MacOS©. La sortie récente de Gajim 0.12 nous redonne espoir.

• Les autres écoles du groupe Centrale (Paris, Lyon, Marseille, Nantes et Pékin) vont-elles suivre ? Avez-vous engagé des démarches à ce sujet ?

L’initiative à Lille était vraiment personnelle et n’a pas fait l’objet de concertation, ni de communication avec les autres écoles. C’est d’ailleurs l’avantage du réseau XMPP, les différents nœuds sont indépendants, contrairement à IRC. Dès que nous aurons un service vraiment convainquant, nous contacterons les différents responsables pour leur en faire la pub et leur proposer de l’adopter à leur tour.

En attendant, je suis en train de chercher des services d’autres serveurs que nous pourrions ajouter dans notre « Service Discovery », en particulier les modules de MUC.

Merci Thomas !

Mon petit doigt continue à me dire qu’il y a encore d’autres services Jabber dans les écoles et universités… Toujours à suivre…

Maxime est étudiant à l’INSA de Toulouse, école d’ingénieur publique généraliste existant également à Lyon, Rennes, Rouen et Strasbourg. Avec l’aide d’autres étudiants et du service informatique de l’école, il a mis en place un service Jabber pour tous les étudiants du campus.

Max s’est prêté au jeu de l’interview : tour d’horizon du service en passant par sa mise en place, la technique, son évolution, son utilisation et ses perspectives.

Peux-tu te présenter brièvement ?

Je m’appelle Maxime Chéramy et je suis étudiant en 3ème année Modélisation, Informatique et Communication à l’INSA de Toulouse.

Quand et comment as-tu eu l’idée de mettre en place un serveur Jabber dans ton école l’INSA de Toulouse ?

L’idée ne vient pas de moi mais ressort du constat d’un besoin plus général :
Historiquement, nous avions un serveur IRC relié au réseau informatique des résidences. Pour diverses raisons, sur lesquelles il n’est pas intéressant que je m’étende ici, ce serveur est devenu contraignant à utiliser et sa fréquentation a lourdement chuté il y a 3 ans environ.
Il y a 1 an et demi nous avons tenté de remettre en place un serveur IRC sur une machine accessible depuis notre réseau VPN mais ça n’a pas duré longtemps car il s’agissait d’une installation de fortune dans l’appartement d’un étudiant et l’IP statique utilisée est redevenue dynamique.
C’était une expérience certes très courte mais qui nous a motivé à faire les démarches nécessaires pour obtenir un vrai serveur de messagerie instantanée pour y héberger des salons de discussion.

Nous (à savoir Vincent, Thibaud, Guillaume, Mathieu, Baptiste et moi) nous sommes rassemblé autour de ce projet pour demander au CRI (Centre des Ressources Informatique) un serveur que nous administrerions nous-même pour y installer un serveur Jabber et d’autres services.

Nous avions le choix entre IRC et Jabber mais le CRI nous a imposé certaines contraintes qui nous a décidé pour Jabber. Le serveur est en place depuis bientôt un an.

Quels sont ces contraintes ?

Principalement :
- Authentification des utilisateurs pour que le serveur ne soit utilisable que par des étudiants de l’école ;
- Les mots de passe ne doivent pas circuler en clair.

Cela devenait vraiment compliqué à faire avec IRC alors qu’avec Jabber c’est plus dans sa logique de fonctionnement.

Quelle démarche as-tu adopté pour convaincre les décideurs ?

Je pense que ce qui a permis de les convaincre c’est que nous avons montré que nous étions motivés, capables et sérieux. Et cela vient certainement du fait que notre projet était suffisamment bien préparé.

J’aimerais en profiter pour les remercier d’avoir accepté notre projet et je voudrais aussi remercier tous ceux qui ont répondu à mes questions et qui ont accepté de partager leurs expériences.

Quelles solutions techniques ont été choisies et pourquoi ?

Après avoir testé différents serveurs Jabber et étudié leurs avantages et inconvénients, notre choix s’est arrêté sur Openfire. Je pense que son point fort réside dans son interface web d’administration. Nous avons pu en quelques clics configurer l’interfaçage avec l’annuaire LDAP et limiter l’accès au serveur aux connexions sécurisées (TLS). Nous pouvons aussi gérer très simplement les salons de discussion.
Les autres serveurs possèdent d’autres qualités qui nous ne sont pas forcement utiles (multi-domaine, cluster, meilleures performances, etc).

Quels services sont offerts à ce jour ?

L’authentification se fait en utilisant l’annuaire LDAP de l’école ce qui permet de fournir automatiquement une adresse Jabber à tous les étudiants. Leur identifiant Jabber est alors identique à leur adresse email.
La connexion serveur à serveur est active ce qui signifie que l’on peut dialoguer avec des personnes extérieurs qui sont sur le réseau Jabber mondial.

Et bien sûr, il y a des salons de discussions (MUC).

Une extension de services est-elle prévue ?

Nous avons un bot que j’ai programmé spécialement pour nos besoins et qui anime entre autre un Quizz et qui annonce sur le salon principal les nouveaux messages postés sur le forum des étudiants.

Bien sûr, si de bonnes idées remontent et qu’elles sont simples à mettre en place, cela sera fait.

Comment est publicisé le service ? Comment est-il perçu ?

Il a été bien accueilli par les étudiants qui sont habitués à l’IRC avec cependant quelques critiques sur les clients Jabber. Il n’y a pas de retours vraiment négatifs puisque ceux qui ne sont pas intéressés ne l’utilisent pas et cela s’arrête là.

L’installation d’un logiciel supplémentaire et sa configuration rebute pas mal de monde. Pourtant, lorsque nous en parlons, les gens trouvent ça sympa. C’est pour cela que nous attendons avec impatience l’arrivé d’un bon client web. Nous en avons essayé plusieurs mais aucun n’est vraiment satisfaisant.

Possèdes-tu quelques statistiques ? Notamment le nombre d’utilisateurs actifs ?

Avant tout, il est nécessaire je pense de décrire la situation pour mieux interpréter les chiffres. L’INSA de Toulouse c’est une école d’environ 2100 étudiants dans le cycle d’ingénieur qui se fait en 5 ans. C’est une école généraliste qui débouche sur une dizaine de spécialisations allant du génie biochimique à la physique en passant par le génie mécanique et l’informatique.
Il s’agit donc d’un public très varié qui n’est pas toujours intéressé par ce type de service et qui utilise déjà MSN, Skype, Gtalk ou d’autres logiciels de messagerie instantanée. De plus, les occasions de se rencontrer en personne sont grandes puisque la majorité des étudiants vivent sur le campus et que nous avons accès à un large panel d’activités grâce à nos clubs et associations.
Et ce n’est pas non plus le seul moyen d’échange entre les étudiants puisque nous possédons aussi un forum assez actif.
Cela étant dit, après un peu moins d’un an, nous avons en soirée une vingtaine de personnes connectées dont une bonne moitié qui rejoint automatiquement le salon principal à la connexion. Ce n’est certes pas énorme mais je suis assez confiant sur l’avenir.

Quelle est votre consommation de ressources ? (question récurrente avant toute mise en place de services)

Le serveur utilisé sert déjà pour d’autres services dont en particulier le serveur web où sont installés entre autre le webmail et le forum (900 000 pages vues/mois). Au final, la consommation CPU du serveur Jabber est insignifiante comparée à Apache+PHP+MySQL et la consommation en mémoire reste raisonnable. Le serveur est un Pentium 4 ‘B’ à 3.06 GHz avec 1 Go de RAM.

Quels sont les points positifs de ce déploiement ?

- Pas de pannes, le serveur est stable ;
- Jabber permet de faire ce qu’IRC permet et plus encore.

Quels sont les axes d’amélioration ?

- Beaucoup de clients Jabber mais pas un seul vraiment convainquant : une impression de logiciels non finis et qui sont loins d’exploiter le potentiel de Jabber ;
- Pas assez d’utilisateurs.

Les autres INSA (Lyon, Rennes, Rouen, Strasbourg) vont-elles suivre ? Avez-vous engagé des démarches à ce sujet ?

Je ne sais pas si les autres INSA vont suivre mais je le souhaite et je suis prêt à aider quiconque voudrait installer un serveur dans son école (INSA ou non).

Merci beaucoup Maxime pour ta disponibilité et ton engagement.

Mon petit doigt m’a dit qu’il y avait beaucoup d’autres services Jabber dans les écoles et universités… À suivre…

L’April a publié une série de trois romans-photo de promotion de la campagne d’adhésion, un bon gros délire de geeks ! Plus original encore, c’est sous forme de QCM, je vous invite à les consulter maintenant :

• Pourquoi l’April a-t-elle besoin de financement ?
• Pourquoi l’April a-t-elle besoin de plus de membres ?
• Pourquoi adhérer à l’April ?

J’en ai parlé dans un post de novembre : « Adhérez à l’April, voici pourquoi c’est nécessaire », je réitère maintenant :

J’appelle tous les utilisateurs de Jabber/XMPP à adhérer tout de suite à l’April car elle défend les standards ouverts tels que Jabber/XMPP : http://www.april.org/adherer

Voici un sondage qui vous permettra une nouvelle fois de vous exprimer.

Cette fois-ci, le sujet est la messagerie instantanée propriétaire : ce que vous détestez le plus.

Jack Moffitt est membre du conseil technique et de la board of directors de la XSF. Il a créé ChessPark le site de jeu d’échecs en ligne. Une série d’articles décrivent le fonctionnement de celui-ci sur son blog « Chesspark Design Details » :

• Part 1: Why XMPP?
• Part 2: Session Handling
• Part 3: Game Design

Il y décrit les fondations XMPP de ChessPark par un vrai retour d’expérience, en commerçant par le choix de XMPP pour son réseau social sous-jacent, le protocole de communication avec ses implémentations et bien évidemment l’instantanéité des échanges (la messagerie instantanée étant un bonus secondaire), puis il explique les mécanismes de présence et de gestion de session mis en œuvre et enfin il entre plus dans le jeu avec les aspects arbitrage et les spectateurs.

Attention, la lecture n’est pas si triviale, il faut connaître a minima le fonctionnement des MUC. Jack va écrire encore un ou deux articles sur le sujet, à suivre de près donc.

Ceci est la preuve par l’exemple et le vécu  que XMPP ne sert pas qu’à la messagerie instantanée. Un serveur XMPP est un vrai serveur d’applications, offrant tout un ensemble cohérent de fonctionnalités très utiles pour bâtir des applications dans bien des cas concrets (certaines de ces applications peuvent effectivement être des jeux).

À ce propos, je vous conseille la lecture de ces articles, c’est très instructif :

• Jabber is more than Instant messaging
• Quand Jabber ne sert pas qu’à la causette
• Introducing the XMPP application server: The Twitter example
• More social networks turn to ejabberd XMPP application server
• Le framework Volity ou tout simplement SamePlace sont des exemples d’applications XMPP.
  

Vous avez voté, vous vous êtes exprimés, vous avez choisi votre client XMPP/Jabber préféré, voici les résultats :

Et voici le fromage :

Gajim et Psi sont en tête, avec respectivement près de 40 % et 20 % des préférences, suivi de Pidgin à plus de 10 % et la famille Google à 5%. Les autres se partagent tout de même près de 30%.

Votre client Jabber/XMPP préféré est sans doute parmi ceux-là, bien que ça ne soit pas une liste exhaustive.

Vous pouvez commenter évidemment, les résultats en live sont à un clic de souris, je donnerai les résultats définitifs dans environ deux semaines.

Thomas Cataldo vient d’intégrer la messagerie instantanée Jabber/XMPP dans l’interface mail MiniG de la suite de groupware OBM. Côté serveur, c’est à Openfire qu’on a affaire. Une vidéo au format propriétaire Flash est disponible en guise de démo.

Zimbra, une autre suite de groupware, intègre également Openfire côté serveur et une interface de chat côté client. On m’a fait la démo devant mes yeux, ça fonctionne, mais je n’ai pas trouvé de vidéo de démo.

Je suis adhérent de l’April depuis plusieurs années, voici pourquoi.

L’April est une association très active et constructive, défendant non seulement le logiciel libre et opensource, mais aussi l’interopérabilité, les standards ouverts et la vie privée des internautes. L’April lutte également contre les brevets logiciels, les DRM (restrictions numériques des droits) et les lois réduisant l’espace des libertés sur internet et dans l’informatique.

L’April œuvre énormément à travers l’organisation des Rencontres Mondiales du Logiciel Libre (RMLL, ou FSM en anglais pour Free Software Meeting) et de nombreux salons, des conférences partout en France, les causeries (dont j’ai été l’interviewé fin 2007), des traductions, l’initiative candidats.fr, et bien d’autres actions.

Cette association m’est chère car les personnes qui y contribuent sont non seulement très intelligents, mais aussi énormément impliqués, à l’écoute et volontaires. Le logiciel libre et les standards ouverts sont fondamentaux (sous la menace constante de la mentalité propriétaire), l’April est en position forte et privilégiée pour les défendre et les promouvoir.

Pourquoi adhérer à l’April ?

Adhérer est un geste peu contraignant, individuel, fort, engageant :

• le montant d’adhésion est au minimum de 10 €, mais préférez 20, 30 ou 50 € voire plus si vous en avez les moyens ;
• il ne s’agit pas de tirer des bénéfices personnels (comme par exemple des réductions dans d’éventuels magasins), mais il s’agit de donner sa voix et ainsi renforcer la position de l’April vis-à-vis des pouvoirs, législateurs, lobbies et administrations ;
• les développeurs contribuent du code… mais les autres, très nombreux, ont dans l’adhésion une manière de contribuer activement au logiciel libre et de construire et de sécuriser sont développement sur le long terme.

Lucas Nussbaum, Alexis Kauffmann et Tristan Nitot en parlent également, mieux que moi, je vous invite à lire leurs billets.

On a passé la barre des 3.000 adhrérents, dont des entreprises et associations, l’objectif est fixé à 5.000.

Veuillez adhérer à l’April : http://www.april.org/adherer. Votre adhésion compte énormément, je compte sur vous. Je vous encourage même à bloguer sur le pourquoi de votre adhésion.

La conférence a eu lieu aujourd’hui, vendredi 2008-11-21 en notation standard ISO 8601, à 14h et à 16h30+.

La première conférence dans l’amphi du bas s’est déroulée devant environ 60 personnes, et la seconde dans l’amphi du haut devant environ 30 personnes. Le public était étudiant, attentionné et a bien réagi, mais peu de questions.

Voici les slides en Flash propriétaire, également disponible sur SlideShare, ou en téléchargement en version originale OpenDocument.

Merci à l’IUT de Reims et à LoLiCA !

Ludovic Gilbon a posté sa présentation XMPP/Jabber effectuée à l’IUT d’info d’Orélans, avec l’aide du LUG Cenabumix.

Désolé, c’est du Flash, c’est propriétaire, mais c’est pour les plus fainéants.

C’est aussi disponible directement sur le site SlideShare, et téléchargement au format standard ouvert OpenDocument.