Il est une idée qui me trotte dans la tête depuis approximativement un an, et il est temps que je la jette sur le papier. Cette idée, c’est la réalisation d’un client Jabber sur la plateforme Mozilla. Quand j’y pense, je suis étonné des possibilités énormes qu’offrirait un tel logiciel.
Genèse
Á l’origine, j’avais pour idée de développer un logiciel d’édition SVG collaboratif sur la plateforme Mozilla. Xulrunner est installé sur des millions de pc grâce à Firefox. SVG progressant plutôt vite dans Gecko, j’avais imaginé une extension aux salles de conférences Jabber pour l’édition de document XML. Au delà des problèmes intéressants de synchronisation que cela pose (et qui ont déjà été discuté, voire les archives des listes de discussion XMPP), ce logiciel aurait aussi permit d’autres choses intéressantes.
La première aurait été de pouvoir faire des présentations sur le Web, à la Powerpoint. SVG permet de faire des présentations de très bonne qualité, sans compter que la version1.2 de ce langage inclura surement des effets de transitions (entre les pages), l’élément <page/>, le son et la vidéo et d’autres fonctionnalités qui feront de SVG un langage qui permet de faire autant de chose que les lourds logiciels de présentation (Powerpoint, Impress) dans un format Web. Pour passer d’une diapo à l’autre, il suffirait de changer des attributs CSS (visibility:hidden ou visibility:visible). Mais l’élément <page/> du futur SVG1.2 se comporte comme un élément d’animation et il aurait suffit de pouvoir, grâce à une commande XMPP, lancer une animation comme on le fait avec la méthode du DOM SVG beginElement().
Cette idée en apporta une autre : il aurait tout aussi bien été possible de réaliser des jeux de plateau ou des jeux de rôle grâce à cette infrastructure. SVG serait utilisé pour les graphismes et XMPP pour modifier les données SVG. Mieux : en utilisant Javascript pour traiter le flux XMPP, on a accès à des possibilités beaucoup plus étendues.
Prenons par exemple un jeu d’échec (pour faire simple). Il est très facile d’étendre le protocole XMPP pour y inclure son balisage spécifique. Avec la découverte des services, on peut facilement savoir si le contact d’en face peut gérer ce balisage. Une fois la partie commencée, l’interface graphique envoie les mouvements des pièces à l’adversaire :
<message from='moi@jeudechec.net' to='lui@sonfournisseur.com'> <chess xmlns="http://jeudechec.net/chessns" type="move" from="D4" to="E6"/> </message>
Et voilà que mon cavalier se déplace en E6.
Du côté de mon adversaire, ce message est traité et une animation est lancée sur son graphique SVG.
Ce système à un inconvénient, c’est qu’il est facile de tricher. Chaque client peut vérifier la cohérence des mouvements des pièces ou alors on peut faire appel à un script côté serveur.
Á ce stade, les possibilités de la plateforme sont déjà sympatiques.
Une extension parmi d’autres
L’idée fit son cheminement jusqu’à arriver à la conclusion suivante : de telles applications (édition SVG collaborative, jeux, etc) ne pourraient finalement qu’être des extensions parmi d’autres dans une plateforme beaucoup plus générique.
Cette plateforme beaucoup plus générique serait un client Jabber basé sur la plateforme Mozilla. Bref, un Firefox de la messagerie instantanée, tout simplement.
Car ce qui a en partie fait le succès de Firefox, ce sont sa légèreté, les possibilités offertes par sa plateforme et ses extensions faciles à créer et à déployer. Et c’est transposable à un client Jabber en XUL.
L’architecture
Á vrai dire, j’ai réalisé un prototype fonctionnel de cette idée un jour de grève générale. Oui, en un jour : c’est la rapidité de développement qu’on peut atteindre avec la la plateforme Mozilla basée sur Xulrunner. Voici une caputre d’écran de ce prototype :
Capture d'écran de Papaya, prototype d'un client Jabber en XUL
Papaya, son petit nom, permet déjà d’afficher la liste des contacts, d’envoyer et de recevoir des messages et de changer sa présence (avec le message qui va avec). Bien sûr, c’est codé à la va vite et le code n’est pas montrable.
Ce qui est important est la manière dont je l’ai réalisé.
Pour la partie Jabber (protocole XMPP), je me suis basé sur la bibliothèque XMPP4Moz qui s’installe comme une extension. Elle gère le protocole de base : presence, message, chat, erreurs. Elle est pratique : on peut désigner des fonctions de callback lors de la réception d’une réponse. De plus, contrairement à certaines bibliothèques Javascript pour XMPP, elle se connecte en TCP grâce aux composants réseaux de la plateforme Mozilla. Les bibliothèques javascript se content de faire du pull ou du push sur HTTP.
Le programme entier est une application Xulrunner. Sous Unix, il suffit de taper
xulrunner application.ini
et le tour est joué. Si Xulrunner n’est pas installé, alors on peut faire :
firefox -app aplication.ini
Pour débugger, vous connaissez sans doute la console d’erreur de Firefox. On peut avoir la même pour développer des applications XUL :
xulrunner application.ini -jsconsole
La gestion du style se fait très classiquement avec CSS. Pour la localisation, on utilise un système basé sur les DTD, très simple.
Le plus, c’est la manière dont XMPP4Moz traite le XML. Ici point de DOM, trop lourd, on utilise à la place E4X qui permet de manipuler du XML directement en javascript. Par exemple :
var message = <message from='expediteur@exemple.net' to='destinataire@exemple.com' xml:lang='fr'> <body>{messageText}</body> </message>;
E4X est parfaitement adapté à la manipulation de fragments de XML qu’on traite avec le protocole XMPP.
Enfin, grâce à l’utilisation d’XBL, les extensions pourront facilement étendre les fonctionnalités.
Les projets existants
Il existe plusieurs projets de client XUL à l’heure actuel.
Le premier est Sameplace, qui est basé sur XMPP4Moz. Sameplace est une extension de Firefox qui permet d’avoir de la messagerie isntantanée dans le navigateur. C’est une très bonne idée dans la mesure où cela rend possible les interactions avec les pages web visités au même moment. Mais à mon avis, un navigateur est déjà assez lourd pour ne pas y inclure en plus un client de messagerie instantané. Essayez, et vous verrez qu’il vous manquera rapidement de la place.
Instantbird est un client standalone en XUL basé sur la célèbre libpurple qui motorise Pidgin et Adium. Ce client est multiprotocole et c’est à mon avis là son principal défaut : gérer plusieurs protocoles qui n’ont pas les mêmes possibilités ralentit le développement et brident les possibilités. Et puis de toute façon, XMPP, comme SMTP à son époque, finira par s’imposer. Pourquoi alors perdre du temps avec les autres protocoles ? (Oui, je sais, ce point est discutable, mais je ne suis pas sûr que développer pour les autres réseaux propriétaires fera migrer d’une quelconque manière les utilisateurs vers Jabber.) Il reste que c’est un logiciel de qualité et la lecture de son code m’a beaucoup appris.
La dernière tentative est un client XUL dans le navigateur du nom de OneTeam, développé par Process One, la boîte à l’origine d’Ejabberd. Encore une fois, le fait que cela se passe dans le navigateur est je pense une mauvaise idée. Bien que tout se fait sur le « Web 2.0″ aujourd’hui, je pense qu’un client standalone a encore sa place sur les bureaux des utilisateurs, qui utilisent bien MSN ou un autre client de messagerie instantanée.
J’aimerais pour ma part tenter cette voix du client standalone.
Les possibilités d’une telle plateforme
Un tel logiciel serait très facilement extensible grâce au gestionnaire d’extension intégré de Xulrunner. Rappelez vous, j’ai intégré XMPP4Moz de cette manière 
Voici une liste des choses qu’il serait possible d’implémenter via des extensions :
- édition collaborative de documents XML à deux ou plus grâce aux salles de discussion : XHtml, SVG, XForms, XSL-FO (si c’est implémenté un jour) ;
- extensions sociales à la Facebook, sans la centralisation dangereuse qui va avec ;
- partage de fichier et basé sur ça pourquoi pas un Darknet : je partage mes fichiers et les fichiers de mes amis et ceux des amis de mes amis ;
- publication avec Pubsub : humeur, ce que j’écoute, activité, photos, etc ;
- extension des salles de conférences, de n’importe quelle manière ;
- grâce à Jingle, il devient possible de gérer les flux de pair à pair ;
- conférence audio et/ou vidéo à plusieurs dans une salle de discussion. En même temps, par exemple, qu’une présentation SVG ;
- ou pendant un jeu ;
- grâce à Jingle (vitesse de transfert élevée et latence faible), on peut imaginer l’utilisation de Canvas pour réaliser des applications (par exemple des jeux) temps réel. Quand Canvas3D sera implémenté, il sera possible de réaliser des applications 3D temps réel ;
- des extensions pourraient proposer des services comme des passerelles téléphoniques ;
- toutes sortes de robots côté serveur pourraient communiquer avec des extensions. Exemple : un jeu de poker en ligne (en SVG, Canvas ou Canvas3d pour les graphismes) ;
- etc
Pour résumer, on pourrait utiliser toute la plateforme Mozilla en temps réels et en mode de collaboration avec sa liste de contact. Le champ des possible devient vaste, autant pour les particuliers que pour les entreprises. Pour ces dernières, il serait possible de construire une suite collaborative complète (audio, vidéo, partage de documents via une pubsub, édition simultanée, etc).
Les difficultés
La principale difficulté de ce projet serait, comme pour beaucoup de client Jabber, l’implémentation de Jingle. Sauf que Xulrunner n’est pas une plateforme multimédia. Je vois ici plusieurs solutions.
La première est d’utiliser ce qui est déjà inclut dans la plateforme, à savoir les formats Theora, Vorbis et Speex. Ce dernier codec sera très probablement inclut très bientôt et ça tombe bien puisqu’il est très utilisé pour la Voip. Reste à savoir s’il est facile d’utiliser ce qui existe déjà dans un cadre où le flux est du véritable streaming. Sans compter que l’inclusion de codecs supplémentaires risque d’être plus difficile…
La seconde solution serait d’utiliser des bibliothèques tierces, et je dois dire que le projet Telepathy qui est le projet de messagerie XMPP de Gnome (pour faire simple) est plutôt attirant. En plus d’un moteur XMPP (qui pourrait remplacer XMPP4Moz), elle intègre tout ce qu’il faut pour établir des connections avec Jingle. Google a aussi sorti une bibliothèque pour ça, libjingle.
La grande question est de savoir si la plateforme est assez robuste pour gérer des flux vidéos et audios…
Voilà où j’en suis pour le moment. Le temps me manque pour commencer un tel projet mais j’en ai parlé autour de moi (et je continue de le faire) et les retours sont positifs, voire très positifs.