sxEdit: rapport

sxEdit

ou

Développement d'une extension Kompozer pour l'Edition Collaborative en Temps Réel

KompoZer

+

XMPP

=

sxEdit

Remerciements

J'aimerais remercier chaleureusement les deux personnes qui m'ont pris sous leurs ailes et sans qui je n'aurais pas pu réaliser le travail que je présente aujourd'hui : il s'agit de Fabien Cazenave et Sonny Piers, qui malgré leur emploi du temps très chargé ont toujours trouvé le temps de répondre à mes (nombreuses) questions.

Je profite aussi de ce moment pour saluer deux camarades de classes, Fabien Rocu et Mathieu Pavard qui m'ont respectivement aidés dans les overlays de KompoZer et dans le design du logo de sxEdit.

Frédéric Eterno (:fred)

Index

Présentation

Bienvenue

En tant qu'étudiant en Master2 MIAGE à l'Université d'Evry dans la promotion 2009:2010, j'ai eu la chance d'assister aux cours dispensés par Fabien Cazenave et Laurent Jouanneau dans le cadre du projet CoMeTe. C'est à l'issue de cette semaine de formation intensive sur les technos Mozilla (essentiellement XUL, XBL et XPCOM) que nous avons dû choisir un projet de la communauté mozillienne pour y contribuer...

L'envie de participer à un projet à la fois utile pour le grand public et ambitieux pour moi-même m'a poussé à rejoindre le projet KompoZer, et plus particulièrement le développement d'une extension permettant l'édition collaborative d'un document en temps réel. Avant de rentrer dans les détails, bref rappel sur le logiciel KompoZer ainsi que la technologie de communications utilisée, XMPP.

Fred.

KompoZer

KompoZer est un éditeur de pages HTML dit « WYSIWYG » (What I See Is What I Get), c’est-à-dire permettant de générer un document web sans qu’il ne soit nécessaire de connaître les syntaxes de HTML ou CSS... et qui attaque donc directement le marché de Dreamweaver et Frontpage.

KompoZer est une version améliorée de Nvu, logiciel libre qui n’est plus maintenu actuellement. Même si Nvu a été publié sous la triple licence MPL/GPL/LGPL, son nom et son logo restent la propriété de la société Linspire, celle qui a commandé la première version de Nvu à Daniel Glazman. C'est Fabien Cazenave (:kaze) qui a reprit la tête de ce développement, et baptisé KompoZer. On notera que Nvu est lui-même issu de Mozilla Composer (obsolète).

Basé sur Gecko, le moteur de rendu Mozilla, KompoZer est très rapide, multi-plateformes et propose une expérience utilisateur moderne grâce aux interfaces XUL. De la même manière que les produits Mozilla les plus connus, il est possible de personnaliser et d'ajouter des fonctionnalités à KompoZer à l'aide d'extensions.

XMPP

XMPP (Extensible Messaging and Presence Protocol) est un ensemble de protocoles standards ouverts de messagerie instantannée et de présence inventé par Jeremie Miller en 1998, développé par la communauté Open-Source Jabber en 1999-2000, formalisé par l'IETF (Internet Engineering Task Force) en 2002-2004, continuellement étendu par la Fondation des Standards XMPP et implémenté au sein d'un grand nombre de logiciels, appareils et services Internet.

Basé sur une architecture client/serveur permettant les échanges décentralisés de messages au format XML, cette technologie ouverte supporte des services de messagerie instantannée, de présence, de chat multi-utilisateurs, de conversations audio et vidéo, de travail collaboratif, de communication entre middlewares, de syndication de contenu...

La force du protocole XMPP réside dans sa séparation en deux parties différentes. D'une part le protocole de base contient les concepts fondamentaux pour faire fonctionner une infrastructure Jabber. Définis dans quelques RFC, ces concepts sont nécessaires au déploiement d'une infrastructure se disant orientée XMPP. D'autre part, les XEP (XMPP Extension Proposal) sont des propositions pour greffer des fonctionnalités au protocole de base. Les serveurs ou clients ne sont pas obligés d'adopter ces extensions mais cela peut bloquer certaines fonctionnalités entre deux utilisateurs. Les XEPs sont constamment créés, révisés et améliorés.

La communauté de la Fondation des Standards XMPP est constituée de nombreux développeurs Open-Source, et est supportée par de grands acteurs de l'industrie des technologies informatiques tels que Google, HP, DreamHost...

Objectifs

Le lecteur à l'aise avec la langue de Shakespeare trouvera la fiche introductive du projet sur cette page.

Il est donc question, dans le développement d'une extension, de permettre à l'utilisateur de KompoZer de partager son document courrant avec un de ses contacts afin de participer à une session de travail collaboratif en temps réel. Des solutions en-ligne proposent déja ce type de fonctionnalité telles que Etherpad ou GoogleDocs. Mais ces solutions ne sont pas simultanément orientées développement web (Etherpad ne supporte que l'édition de texte), temps réel (GoogleDocs souffre d'un délais de rafraichissemet trop long), et sécurité (plusieurs personnes peuvent modifier le même élément, ce qui peut être source de conflits).

Ce sont les axes majeurs couverts par l'extension: le socle de KompoZer offre les outils propres au développement web, l'infrastructure XMPP garantit des performances de réactivité digne d'une messagerie instantannée et l'utilisation conjointe de certaines XEP et des technologies du web (DOM/JavaScript/CSS) couvre les besoins élémentaires de sécurisation lors d'un travail collaboratif.

C'est la XEP-SXE (Shared XML Editing), spécialisée dans l'édition collaborative de données XML et encore à l'état de brouillon, qui a été choisie pour établir les échanges de noeuds du document. Ce protocole est principalement destiné à être utilisé au dessus de XMPP sur des applications de messagerie ou des clients spécialisés dans l'édition. Cela dit, ce protocole pourrait aussi être utilisé sur une connection TCP directe. SXE utilise une autre XEP très interessant pour la gestion de sessions multimédias: Jingle.

Suivi du projet

Planning 2009:2010

Semaines 1:2 (16:23 Nov)

  • Sélection du projet: Edition Collaborative en Temps Réel sous KompoZer (kDocs, puis sxEdit)
  • Tâches administratives: page descriptive du projet, enregistrement du pseudo IRC, ouverture du blog...
  • Contributeurs: kaze & Sonny

Semaines 3:6 (12 Dec:04 Jan)

  • Preparation de la version 0.1: Elaboration d'une première feuille de route
  • Préparation de la version 0.1
  • Lancement de la 0.1: kDocs 0.1
  • Démonstrations étudiants: Aymeric (sFTP pour KompoZer), Fabien (DOM Explorer Advanced pour KompoZer), Seb (Easy CSS pour KompoZer), Fred (kDocs pour KompoZer), Chipo (Blogger interface pour KompoZer)

Semaine 7 (11 Jan)

  • Démonstrations étudiants: Matiew (ReserveIT pour Sunbird), Côme (Video previsualisation pour InstantBird), Johan (Skin Templating pour InstantBird), Naushad (Multi copy/paste pour InstantBird), Renaud & Raf’ (Processing.js)

Semaines 8:10 (18 Jan:01 Fev)

  • Preparation de la version 0.2
  • Démonstrations étudiants: William, Antoine, Hamid, WomoZ
  • Preparation de la version 0.2
  • Lancement de la 0.2: sxEdit 0.2 (changement de nom)

Semaines 11:13 (15 Fev:01 Mar)

  • Preparation de la version 0.3
  • Preparation de la version 0.3
  • Lancement de la 0.3: sxEdit 0.3

Semaine 14:18 (08 Mar:06 Avr)

  • Preparation de la version finale et des présentations du projet
  • Version finale
  • Présentation orale du projet et rapport

Avancement

Une fois mon projet choisi, je me suis rapproché de kaze et sonny afin de lancer les discussions autour de l'interface utilisateur. Sujet très cher à kaze, j'ai apprécié son implication dans les débats constamment alimentés par sonny... :) Après que nous ayions décidé de loger l'extension dans la barre latérale (sidebar) de KompoZer, j'ai produit les quelques maquettes suivantes.

Premiere maquette

Fig1: Première maquette

Cette première maquette situe la position de la sidebar (latérale gauche). L'onglet affiché recense la liste des participants de la session collaborative, un onglet replié (en bas à droite) abrite le module de messagerie instantannée, et enfin le document courant (au centre) est coloré en fonction de la personne qui édite le noeud.

Revision de la sidebar

Fig2: Révision de la sidebar

Plus tard, par soucis d'ergonomie, nous avons décidé de fusionner les deux onglets de l'extension afin de concentrer la gestion des collaborateurs et les discutions instannées sur un unique panneau.

Originellement estampillée kDocs v0.1, j'ai présenté une application autonome nécessitant uniquement l'environnement xulrunner pour s'éxecuter. Si ce premier rendu n'avait pas encore la forme d'une extension KompoZer, c'est parceque ce dernier n'utilisait pas encore la dernière version de Gecko. Or, la librairie xmpp4moz (développée par bard dans SamePlace pour Firefox) se chargeant des communications XMPP nécessitait une version Gecko à jour (Gecko v1.9 à ce moment là). Cette application pouvait utiliser le réseau Jabber (XMPP) pour récupérer une liste de contacts, permettre l'échange de stanzas et commencait l'implémentation de la XEP-SXE : la première version de Mapper (traitement de parsing DOM du document courrant afin de constituer une stanza d'initialisation) était fonctionnelle.

Il est à noter que sonny m'a fourni le squelette du projet Papaya afin de constituer une base de travail.

Options XMPP utilisateur

Fig3: Informations du compte utilisateur XMPP

L'utilisation du réseau XMPP nécessite des identifiants qu'il est possible de renseigner dans une petite fenêtre de préférences.

Squelette GUI

Fig4: Squelette de l'interface utilisateur

Cette première version propose une interface rudimentaire, mais néanmois fonctionnelle afin de se connecter au réseau XMPP, rejoindre la MUC, et envoyer l'état du document courant. Sous ces bouttons, on trouvera la liste des individus connectés à la MUC.

La sortie de la mouture 0.2 vit le nom du projet changer pour sxEdit (comprendre Shared XML Editing). Le plus grand changement apporté par cette nouvelle version est le passage d'une application stand-alone à une extension KompoZer. Ce n'est pas moins d'un week-end acharné avec kaze qui nous a permis d'effectuer cette migration: pour assurer le succès de l'opération, kaze réalisa la toute première compilation de KompoZer v0.8a1pre pour MacOSX 10.5 (Leopard).

Il nous fallu ensuite cantonner l'interface utilisateur à la barre latérale de KompoZer: une barre d'outil pour réaliser les opérations XMPP (connexion/deconnexion, mapping...), une zone affichant la liste des participants à la MUC rejointe et un espace de chat. Concrètement, il était maintenant possible de partager l'état du document en cours avec une personne présente sur une MUC temporaire, tout en conversant avec elle dans la zone réservée. De plus, de nouvelles idées concernant le comportement général de l'extension furent aussi évoquées lors de la sortie de cette v0.2. Mais cette nouvelle version souffrait d'un bug important: le Mapper était compatible XML, mais pas SGML. Or, HTML est issu des normes SGML et bien qu'étant un langage de balises, n'est généralement pas valide XML... (pensez aux éléments <br>...)

sxEdit devient une extension

Fig5: sxEdit devient une extension

Finalement, la version 0.3 de sxEdit apporta son lot d'améliorations : le bug du Mapper fut corrigé (la lecture du DOM d'un document HTML ne pose donc plus de problème), les premières briques de la couche Jingle furent posées, l'intégration de la librairie xmpp4moz fut amélioré, de nouveaux composants graphiques firent leur apparition telles que des boites de dialogues et des barres de progression et le code fut totalement éclaté et réorganisé pour gagner en clarté. Une nouvelle fonction cachée 'treeCache' peut aussi être apperçue lorsque l'on fouillera dans le code: il s'agit d'une reflexion en cours autour d'une manière optimisée de stocker localement des correspondances entre le DOM original et le document partagé.

La réorganisation du code m'a permis de supprimer complètement de cette release 0.3, les reliquats de codes sources Papaya.

Nous avons aussi mis le doigt sur certaines limites de cette version: même si deux contacts peuvent maintenant s'échanger le contenu d'un document et le reconstruire à l'identique chacun sur leur KompoZer, il semblerait que la taille des stanzas nécessaires à cette synchronization dépasse les limites par défaut des serveurs XMPP. Dans le meilleur des cas, quelques secondes seront nécessaires au passage de la stanza entre les deux collaborateurs; dans le pire des cas, le serveur renverra une erreur de type 'stanza is too big'. L'implémentation complète de Jingle devrait permettre de palier à ces deux lacunes.

La version 0.3 de sxEdit n'est donc pour le moment pas utilisable en l'état. L'implémentation du protocole défini par la XEP-SXE n'est pas achevé et le support de Jingle n'est pas vraiment fonctionnel. De plus, la librairie xmpp4moz utilisée jusqu'à maintenant comporte encore des bugs qui nuisent à la stabilité générale de l'extension. Mais les bases ont été posées, et c'est certainement ce qui comportait le plus grand challenge. La mapping, l'envoi et la reconstruction d'un document à l'identique dans le KompoZer d'un collaborateur en utilisant le réseau XMPP comme support de transport est déja un proof of concept très excitant. Quoiqu'il en soit, l'achèvement de l'aventure CoMeTe ne devrait en rien entacher l'avenir de sxEdit, car continuer le projet avec le support de la communauté OpenSource est pour moi une évidence. Qui peut abandonner un projet prometteur inachevé ?

Acteurs / Contributeurs

Deux personnes m'ont activement soutenues durant tout ce projet : il s'agit de Fabien Cazenave (:kaze) et Sonny Piers (:sonny).

kaze est le Lead Developer de KompoZer, et il m'a confié le développement de sxEdit. Virtuose du XUL, très au fait des besoins de ses utilisateurs et pointu dans le domaine de l'ergonomie, kaze a su me diriger tout au long de cette aventure.

sonny est le Lead Developer de Papaya, une solution de messagerie XMPP utilisant les technologies Mozilla. Son expertise de XMPP et sa pugnacité m'ont permis d'appréhender de la meilleure manière la librairie xmpp4moz. De plus, sonny a gracieusement mis à ma disposition son serveur XMPP personnel durant le développement de sxEdit.

picture of kaze

kaze

picture of sonny

sonny

Communication

Différents canaux de communications ont été utilisés tout au long du projet, et particulièrement ceux qui me reliaient à kaze et sonny, à savoir le canal IRC #kompozer sur irc.mozilla.org et le salon papaya@conference.papaya.im sur le serveur XMPP papaya.im

Une présentation formats PDF (en) et Keynotes (en) a accompagné la sortie de la v0.1. Il s'agissait principalement d'expliquer à mes camarades de classes l'objectif du projet.

Afin d'étendre la visibilité du projet, kDocs fit son entrée sur SourceForge.net le 16 janvier 2010. Le projet fut ensuite renommé en sxEdit, et mis à disposition ici. Cette page devrait prochainement être agrémentée d'un wiki et de la documentation nécessaire aux développeurs souhaitant contribuer au projet. Il est aussi prévu d'alimenter ce portail avec une documentation utilisateur.

Une présentation présente l'état actuel du projet, à la fin de l'expérience CoMeTe (v.0.3) : PDF (en) et Keynotes (en).

Logo

Mathieu Pavard m'a beaucoup aidé lors de la réalisation du logo sxEdit. Concepteur de la version 1 de ce logo, il a pris part à son amélioration jusqu'à la dernière version en date.

Voir la galerie

Techniques et technologies

Protocoles

XMPP

XMPP (Extensible Messaging and Presence Protocol) est une technologie ouverte pour les communications temps-réel en utilisant XML (Extensible Markup Language) comme format de base pour l'échange d'information. Très performante dans le domaine de la messagerie instantannée, cette technlogie couvre aussi des champs inter-applicatifs tels que le monitoring de parcs logiciels. Il n'est pas question ici d'expliquer au lecteur le fonctionnement complet du protocole, Peter Saint-André le fait déja très bien dans son ouvrage. Je me propose seulement d'expliquer quelques notions simples afin d'appréhender du mieux qu'il soit la suite de la lecture.

Par essence, XMPP fournit un moyen d'envoyer des petits bouts de XML d'une partie à une autre. Lors de l'établissement d'une session avec un serveur XMPP, on ouvre une connexion TCP puis on négocie un flux XML avec le serveur. Une fois ce flux négocié et établi, on peut échanger trois fragments XML spéciaux avec le serveur: <message />, <presence /> et <iq />. Ces fragments, appelés stanzas XML sont l'unité des communications XMPP.

La stanza <message /> est la méthode 'push' basique pour faire transiter une information d'un endroit à un autre. Elle n'est générallement pas accusée d'un retour, on peut les considérer comme une sorte de message sans suivi. Les <message /> sont utilisés dans le cadre de la messagerie instannée, les salles de conférence, les alertes et notifications et bien d'autres applications.

Une des fonctions des systèmes de communications en temps réel est la présence et l'état des parties, qui est considérée grâce à la stanza <presence /> en XMPP: elle permet d'avertir la disponibilité sur le réseau d'autres entités et ainsi de faire savoir si elles sont en-ligne et prête à discuter.

La stanza <iq /> (Info/Query) fournit une structure d'interactions requêtes-réponses similaire aux méthodes GET, POST et PUT de HTTP. Contrairement aux <message />, une stanza IQ peut inclure seulement une seule charge qui définit la requête ou l'action à éxécuter par le destinataire. De plus, la réception d'une stanza doit toujours se solder par l'envoi d'un accusé de réception. Les requêtes et les réponses sont suivies en utilisant l'attribut ID qui est généré par l'entité émétrice et inclus dans les réponses suivantes.

Jingle

Jingle est une extension du protocole XMPP pour initier et gérer des sessions multimédia peer-to-peer entre deux entitées XMPP d'une manière qui est interopérable avec les standards Internet existant. Ce protocole fournit un modèle de connexion qui autorise l'utilisation d'une grande variété de type d'applications (conférences vidéo/audio, transfert de fichier...) ainsi qu'une grande variété de méthodes de transport (TCP, UDP, ICE...)

Le protocole SXE défini ci-après est une sur-couche de Jingle.

SXE

La spécification XEP-SXE (Shared XML Editing) définit un protocole pour l'édition collaborative de données XML. Ce protocole définit essentiellement une manière simple de synchronizer entre différentes parties un ensemble d'enregistrements non triés. Ce protocole définit aussi les relations entre cet ensemble de noeuds et un Document Object Model (DOM), tel que le document courant de KompoZer par exemple...

Une fonction spéciale de ce protocole, en comparaison à la plupart des autres outils d'édition collaborative, est qu'aucune entité ou serveur maître n'est requis. Une salle de conférence XMPP (MUC) peut néanmoins être utilisée si une session a un nombre élevé de participants, si elle nécessite d'être persistente ou si elle nécessite une gestion des accès plus fine. C'est cette infrastructure qui a été choisie dans le cadre du projet sxEdit.

Afin d'établir une session de travail collaboratif en utilisant SXE, une partie envoie une requête Jingle d'initiation de session à une autre partie, grâce à une <iq /> en spécifiant l'herbegeur du document (la MUC dans le cas de sxEdit). Comme il s'agit d'une IQ, le destinataire renvoie aussitôt un accusé, avant d'accepter ou de refuser la session.

Stanza d initiation de session

Fig6: Stanza d'initiation de session

Stanza AR de de l initiation de la session

Fig7: Stanza d'accusé de réception de l'initiation de la session

Stanza d acceptation de la session

Fig8: Stanza d'acceptation de la session

Stanza AR de l initiation de l acceptation

Fig9: Stanza d'accusé de réception de l'initiation de l'acceptation

Une fois la session établie, le nouveau collaborateur pourra demander l'état actuel du document à l'aide d'une stanza <message /> contenant un élément <connect />. Après une série d'offres (chaque participant peut prétendre à envoyer une version du document), c'est généralement l'initiateur de la session qui a ensuite à charge de divulguer l'état actuel du document, en envoyant une stanza <message /> contenant un élément <state />.

Stanza de synchro

Fig10: Stanza de synchronization

Cette stanza <message /> est un exemple fourni dans la documentation de la XEP-SXE qui permet à une partie de communiquer l'état du document courrant à une autre partie. Elle représente une table de correspondance qui affecte un identifiant unique à chaque entité du document HTML (élément, attribut, commentaire...). Le destinataire qui reçoit cette stanza et qui implémente le protocole SXE devrait être en mesure de reconstruire le DOM original du document de l'émetteur.

La synchronisation initiale achevée, il est ensuite possible pour chaque partie d'envoyer aux autres les modifications effectuées, grâce à des stanzas <message />

Stanza d edition A

Fig11: Une stanza d'édition

Stanza d edition 2

Fig12: Une autre stanza d'édition

Et voici le DOM résultant de ces éditions successives...

Document final

Fig13: Document visible par toutes les parties après les éditions successives

Comme on l'aura constaté, le protocole SXE 'applati' le DOM du document partagé et affecte une ID à chaque élément, attribut et noeud texte. Un système comparable à des pointeurs vers l'élément parent est alors mis en place, permettant de retrouver et replacer chaque noeud.

Architecture

KompoZer fait tourner l'extension sxEdit; cette dernière utilise l'extension xmpp4moz afin d'établir des connexions TCP et rejoindre le réseau XMPP. L'identification de l'utilisateur est effectuée au niveau d'un serveur Jabber qui communiquera avec le serveur sxEdit défini (papaya.im) lui-même hébergeant les salons de discussion (MUC) nécessaires à la découverte de collaborateurs.

Architecture sxEdit

Fig14: Architecture globale de l'intégration de sxEdit entre KompoZer et XMPP

La librairie xmpp4moz a été développée pour l'extension Sameplace de Firefox, et nous avons modifé son fichier install.rdf afin qu'elle s'installe sur KompoZer. L'extension xmppdev, qui ne figure pas sur ce schéma, a été très utile pour monitorer les communications XMPP. Mais elle a uniquement un rôle de debug pour les développeurs.

Dans le cadre du développement de sxEdit, c'est le serveur privé de messagerie instantanné papaya.im, mis gracieusement à disposition par sonny, qui a été utilisé. La version 1.0 de sxEdit devrait autoriser l'utilisateur à choisir le serveur XMPP de son choix.

Interfaces

Les interfaces ont été programmées en XUL, le langage XML de description d'interface utilisateur sponsorisé par Mozilla. Le nombre de fichiers reste cependant très réduit car seuls les deux fichiers siderbar.xul et options.xul sont nécessaires. Le premier est chargé grace à une redéfinition du panneau latéral, panels-sxe.rdf, et contient une barre d'outils permettant à l'utilisateur d'effectuer les actions de connexion à XMPP et de synchronisation du document courant, ainsi que la liste des participants à une MUC, et enfin une zone de discussion pour dialoguer avec les membres.

Le fichier options.xul permet à l'utilisateur de l'extension de renseigner ses informations de connexion au réseau Jabber telles que son nom d'utilisateur, son mot de passe, le port à utiliser, le nom de la ressource XMPP à utiliser...

Sidebar sxEdit

Fig15: La sidebar de sxEdit

Moteur

Manipulation du XML en Javascript

Très rapidement, il m'a fallu lire et générer des noeuds XML, utilisés dans le cadre des communications XMPP. C'est alors que j'ai découvert E4X (ECMAScript pour XML), extension de Javascript implémenté dans SpiderMonkey, l'interpréteur JS de Gecko. E4X est aussi intégré à ActionScript, le langage de programmation de Adobe Flash/Flex.

La documentation E4X du Mozilla Developer Center, conseillée par sonny, m'a vraiment permis de comprendre les mécanismes de l'outil: le lecture, l'écriture, la gestion des attributs et des espaces de noms... Tout y est expliqué.

Creation IQ

Fig16: Méthode de création d'une IQ

Comme on peut le voir sur l'extrait ci-dessus, écrire du XML en Javascript sous Gecko est vraiment simple. On commence par définir l'espace de nom à utiliser (très important lorsqu'il s'agit d'associer un élément à son contexte), puis on créé un objet XML que l'on replit avec du texte.

Lors de mes premières expériences avec E4X, je me souviens avoir vécu de très mauvais moments car je n'arrivais pas à lire une stanza reçue. Ce n'est qu'après de longues heures de recherches que sonny a volé à mon secours: j'avais oublié de spécifier l'espace de nom des éléments que j'essayais de lire...

Mapping/Unmapping SXE

Les fonctions contenues dans le fichier sxeFirstSync.js sont appelées lorsqu'une synchronisation de l'état du document est lancée.

Les deux mécanismes principaux du projet y sont développés et permettent de mapper le document courant de KompoZer afin de le transformer en ensemble d'enregistrements à envoyer suivant la définition de SXE, puis de unmapper ces enregistrements pour reconstruire le document à l'identique sur un dans le KompoZer d'un collaborateur distant.

Le mapping consiste en un parcours récursif du DOM. A chaque entité trouvée, élement - attribut - texte - processing instruction - commentaire - doctype, un nouvel enregistrement <new /> est créé avec une nouvelle ID et pointant vers l'enregistrement du noeud parent. Une fois tout le document parcouru, la stanza SXE <state /> est remplie avec les <new /> fraichement créés, puis elle est envoyée. J'ai eu des difficultés à concevoir cette fonction car parser du HTML nécessite de prendre quelques précautions, en effet HTML n'est pas forcément valide XML... Les éléments HTML <br> n'étant pas fermés, mon implémentation première tendait à chercher (en vain) des éléments fils. Une correction mineure du code m'a permis de palier à ce défaut, et de rendre compatible sxEdit avec HTML.

Mapping sxEdit

Fig17: Mapping du document

Les fonctions getSXEElement(), getSXEText(), getSXEProcessingInstruction() sont définies plus loin dans le code et permettent de générer les éléments <new />

Le destinataire de la stanza <state /> devra quant à lui suivre le processus d'unmapping, c'est à dire qu'à partir d'un ensemble d'enregistrements <new />, il devra recréer un document identique à celui de l'emetteur.

Unmapping sxEdit

Fig18: Unmapping du document

Communications XMPP avec xmpp4moz

Dès le début du projet, sonny a fait mention d'une librairie conçue pour la plateforme xulrunner permettant le support des transmissions XMPP. Il s'agit de xmpp4moz, développée en premier lieu pour un client Jabber Firefox, Sameplace. Je ne cacherai pas au lecteur que prendre en main cette API s'est révelé ardu.

Pour donner une brève idée de la manière dont ont peut utiliser cette librairie, je propose le code JavaScript simple ci-dessous.

Exemple utilisation de xmpp4moz

Fig19: Exemple d'utilisation de l'API xmpp4moz - Connexion/Deconnexion au réseau XMPP

Le code montré en Fig19 nous montre comment manipuler l'objet phare de cette librairie, l'objet XMPP. Ce objet permet de récupérer toutes les informations concernant l'utilisateur (jid, resource, serveur...) et d'effectuer des opérations élémentaires telles que la connexion/déconnexion au réseau et l'envoi de stanzas.

Autre facette de la librairie, la gestion des évènements (envoi et réception de stanzas XMPP) grace à l'objet channel. Comme on peut le voir ci-dessus, pour peu que l'on soit à l'aise avec le parcours XML e4x, il est très facile d'élaborer une gestion très précise des évènements. Ainsi, l'extrait nous montre comment filtrer les messages provenant d'une MUC. Mais sxEdit contient des filtres bien plus élaborés, tels que ceux utilisés pour la gestion des protocoles Jingle et SXE.

Ouverture

Comme annoncé précédement, la version de sxEdit n'est actuellement pas fonctionnelle. Mais j'ai bon espoir de reprendre le développement prochainement, une fois que je serai dégagé de mes contraintes universitaires. Je suis fier de participer à l'élaboration d'une telle fonctionnalité qui devrait offrir une nouvelle dimension collaborative à KompoZer.

Le bilan que je tire de toute cette aventure est très positif. Malgré les difficultés que j'ai rencontré lors de l'apréhension de technologies qui m'étaient jusqu'alors inconnues, je me suis vraiment amusé et épanoui. J'ai découvert des passionés qui m'ont inculqués une philosophie de travail et introduit dans le monde de l'Open Source. C'est ainsi que j'ai participé au FOSDEM 2010 de Bruxelles, accompagné de sonny et kaze ;)

L'expérience CoMeTe m'a vraiment permis de gouter au Libre, plus comme acteur que consommateur. Et j'ai adoré. Au même titre que des convictions politiques ou religieuses, le Libre rassemble des femmes et des hommes partageant des idées fondamentales pour faire avancer la société : le partage et l'accès à la connaissance, la liberté d'un choix technologique, la transparence des systèmes, l'amélioration continue... Et dans un monde en constante mutation qui se diversifie jour après jour, et où personne n'est logé à la même enseigne, le Libre apporte une réponse pertinente à la question: "Quel héritage pour les générations futures ?"

Fred.

last update : 2010.03.12 | contact : frederic dot eterno at gmail dot com | think before print | download pdf