Université catholique de LouvainEcole polytechnique de Louvain

Département d’ingénierie informatique

Un outil de réunions à distance pour ClarolineA distance meeting tool for Claroline

Promoteur : Lecteurs :Marc Lobelle Philippe Dekimpe

Adrien Coyette

Mémoire présenté parCédric Vanderperren

en vue de l’obtention du titre deMaster 120 crédits en sciences informatiques

option software engineering and programming systems

Louvain-La-NeuveAnnée académique 2009 - 2010

Table des matières

1 Introduction 5

2 Choix stratégiques 82.1 Plateforme d’exécution . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Définition du Web . . . . . . . . . . . . . . . . . . . . 82.1.2 Applications Web comparées aux applications natives 10

2.2 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Technologies utilisées côté serveur . . . . . . . . . . . 132.2.2 Technologies utilisées côté client . . . . . . . . . . . . 14

2.3 Outil et méthodes de développement . . . . . . . . . . . . . . 172.3.1 HaXe comme outil de développement de la partie client 172.3.2 Bibliothèques et format de données . . . . . . . . . . . 192.3.3 Découpage de l’application en différents modules . . . 20

2.4 Fonctionnalités et interface utilisateur . . . . . . . . . . . . . 212.4.1 Présentation des fonctionnalités principales . . . . . . 212.4.2 Modélisation de l’activité d’un client . . . . . . . . . . 23

3 Gestion de la communication client - serveur 253.1 Etablissement d’une connexion bidirectionnelle . . . . . . . . 25

3.1.1 Technique du (long) polling (AJAX) . . . . . . . . . . 263.1.2 Utilisation de sockets . . . . . . . . . . . . . . . . . . . 28

3.2 Présentation des WebSocket du langage HTML5 . . . . . . . 293.2.1 Définition du protocole WebSocket . . . . . . . . . . . 303.2.2 Présentation de l’API WebSocket du langage HTML5 323.2.3 Développement de l’utilitaire : Passerelle avec Flash . 33

3.3 Stratégie de communication et format des messages . . . . . . 373.3.1 Recherche de l’optimisation de la communication . . . 373.3.2 Utilisation du format JSON . . . . . . . . . . . . . . . 393.3.3 Création d’un format minimaliste . . . . . . . . . . . . 39

3.4 Développement du module . . . . . . . . . . . . . . . . . . . . 443.4.1 Développement de la partie client . . . . . . . . . . . . 443.4.2 Développement de la partie serveur . . . . . . . . . . . 45

3

4 Développement du tableau blanc collaboratif 474.1 Objectifs visés et moyens de les atteindre . . . . . . . . . . . 47

4.1.1 Technologies choisies . . . . . . . . . . . . . . . . . . . 484.1.2 Moyens de les utiliser conjointement . . . . . . . . . . 51

4.2 Emploi du patron de conception MVC . . . . . . . . . . . . . 524.2.1 Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2.2 Vues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.3 Contrôleur . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Développement du module . . . . . . . . . . . . . . . . . . . . 574.3.1 Implémentation du modèle . . . . . . . . . . . . . . . 574.3.2 Implémentation du contrôleur . . . . . . . . . . . . . . 574.3.3 Implémentation des vues . . . . . . . . . . . . . . . . . 60

5 Développement de la vidéoconférence 635.1 Intérêt de Flash pour la partie client . . . . . . . . . . . . . . 645.2 Intérêt de HaxeVideo pour la partie serveur . . . . . . . . . . 655.3 Développement du module . . . . . . . . . . . . . . . . . . . . 65

5.3.1 Gestion des vidéos . . . . . . . . . . . . . . . . . . . . 665.3.2 Envoi de la vidéo . . . . . . . . . . . . . . . . . . . . . 665.3.3 Rception de la vidéo . . . . . . . . . . . . . . . . . . . 675.3.4 Gestion des places privilégiées . . . . . . . . . . . . . . 67

6 Intégration dans Claroline 706.1 Définition d’un module Claroline et choix liés . . . . . . . . . 706.2 Respect des conventions de codage et autres conseils . . . . . 726.3 Présentation détaillée du module Claroline . . . . . . . . . . . 726.4 Développement du module . . . . . . . . . . . . . . . . . . . . 75

6.4.1 Base de données . . . . . . . . . . . . . . . . . . . . . 756.4.2 Librairies développées . . . . . . . . . . . . . . . . . . 766.4.3 Gestion d’un ensembles de réunions . . . . . . . . . . 786.4.4 Accès à une réunion en ligne . . . . . . . . . . . . . . 79

6.5 Améliorations envisageables . . . . . . . . . . . . . . . . . . . 806.5.1 Envoi des slides intégré . . . . . . . . . . . . . . . . . 806.5.2 Gestion de réunions périodiques . . . . . . . . . . . . 806.5.3 Droits d’accès et intégration avec les groupes . . . . . 81

7 Conclusion 82

Bibliographie 85

A Manuel utilisateur de l’utilitaire pour les WebSockets 88

B Manuel utilisateur de l’outil de réunions en ligne 90

C Code source 93

4

Chapitre 1

Introduction

L’apprentissage de nouvelles matières peut être réalisé de différentes ma-nières. Il y a d’une part les cours magistraux qui ont pour avantage deprésenter des notions et des concepts à un large public à l’écoute de l’en-seignant. Le style et l’intonation de l’orateur, les supports utilisés (slides,transparents, ...) et bien sûr la manière d’aborder le sujet sont autant de fac-teurs qui auront un impact sur la compréhension de cette nouvelle matièrepour l’étudiant. D’autre part, les séances de travaux pratiques constituentsouvent un complément idéal pour que l’étudiant s’exerce lui-même sur cettematière tout en ayant un tuteur présent pour lui apporter une aide personna-lisée. D’autres moyens, complémentaires ou non, existent et méritent d’êtremis en avant. Ainsi, des petites réunions entre étudiants et professeur oututeur qui se déroulent à rythme régulier, hebdomadaire par exemple, ontpour avantage de laisser l’étudiant découvrir tout ou partie de la matièrepar lui-même puis de soulever ses interrogations lors de ces réunions. Lepeu d’étudiants présents encourage à réduire la timidité et ainsi à poser sesquestions de manière plus libre. Ce mode d’apprentissage a été utilisé dansplusieurs cours donnés par Marc Lobelle, promoteur de ce mémoire, à l’Uni-versité Catholique de Louvain. Une difficulté de ce mode d’apprentissageréside dans le fait que ces réunions sont bien souvent de courte durée et iln’est pas toujours simple de trouver une date qui convienne parfaitement àtous les participants et au professeur. De plus, beaucoup d’étudiants n’ontpas de logement à Louvain-La-Neuve et doivent donc faire de long trajetspour assister à ces réunions. Le professeur peut lui aussi être amené à partirà l’étranger une ou deux semaines sur le quadrimestre.

Depuis le début des années 2000, Internet n’a cessé de gagner en popu-larité. Il permet l’accès à des ressources qu’elles soient textuelles, audio ouvidéo de manière simple et ce partout dans le monde. Ces dernières années,les prix n’ont fait que baisser ou du moins les volumes de téléchargementont augmenté. A cela s’ajoute la bande passante qui tend à être augmentée

5

partout et ce grâce à la fibre optique. C’est ainsi que de plus en plus depersonnes peuvent regarder des vidéos en streaming et en haute définitionde chez eux, en quelques clics. Internet a aussi apporté une nouvelle dimen-sion à l’apprentissage où le terme e-learning est ainsi couramment utilisépour tout ce qui se rapporte à l’apprentissage sur ou avec Internet. C’estainsi que des plateformes de cours comme Claroline, projet né à l’UniversitéCatholique de Louvain, sont arrivées avec leur multitude d’avantages pourl’étudiant et pour le professeur. Le professeur peut ainsi publier ses slides outransparents et les rendre accessibles directement à l’ensemble des étudiantsqui suivent son cours. Cela va plus loin, il peut communiquer des annoncesque l’étudiant reçoit instantanément dans sa boîte de messagerie électro-nique. Les étudiants peuvent prendre contact avec l’équipe d’encadrementà l’aide des forums de discussion ou encore de manière privée par courrierélectronique. Internet est donc un moyen fabuleux qui fait presque oublierla distance physique qui existe entre les personnes et permet un accès libreet direct à l’information.

Dans cette introduction, deux choses ont été mises en avant. Il y a d’abordl’utilité des réunions entre étudiants et professeur avec le défaut des distancesphysiques que chaque participant doit parcourir pour assister à la réunion. Ily a ensuite l’utilité d’Internet avec l’avantage de mettre en contact différentespersonnes de manière directe sans nécessiter un déplacement physique. C’estainsi qu’est née l’idée du promoteur de ce mémoire de créer un outil qui tirerapartie d’Internet pour rendre ces réunions accessibles en ligne pour tous lesparticipants.

Comme discuté précédemment, la plateforme Claroline est constituée demultiples outils que le gestionnaire d’un cours peut utiliser comme il le sou-haite. Les étudiants de l’UCL (Université Catholique de Louvain) connaissentbien cette plateforme nommée là-bas iCampus. Il paraissait donc comme uneexcellente idée d’intégrer cet outil de réunions à cette plateforme d’appren-tissage. En effet, même si le nombre d’outils fournis est élevé, il ne comportepas en soi un outil de réunions, et plus particulièrement, de réunions qui sepassent en ligne.

Dans ce mémoire, il sera d’abord question des choix stratégiques qui ontété pris. Ensuite, il sera expliqué comment a été pensée la communicationclient - serveur, qui inclut le développement d’un utilitaire pouvant êtreréutilisé pour un grand nombre d’applications interactives. Les deux cha-pitres qui suivront s’intéresseront au développement d’un tableau blanc col-laboratif (Whiteboard) pour le premier et au développement de la vidéocon-férence pour le second. Enfin, il sera question de l’intégration de l’outil dansla plateforme Claroline. En effet, cet outil a été développé en outil individuel

6

puis a été totalement intégré au sein de Claroline. Cette manière de faire al’avantage que l’outil pourrait aisément être réutilisé dans d’autres contextesou pour d’autres plateformes.

Pour terminer cette introduction, il me semble important de mentionnerque l’accès simple et rapide au plus grand nombre si pas la totalité des utili-sateurs a été pris en compte et ce dès le début. L’outil se veut être utilisablequel que soit le système d’exploitation utilisé (Windows, Mac OS, Linux,Solaris ou autre) et quel que soit le navigateur employé. En effet, l’outil seveut notamment être totalement compatible avec Internet Explorer 6, utiliséencore par près d’une personne sur dix en juin 2010 dans le monde et par 1personne sur 20 en Belgique pour la même période. Mais, si la compatibilitéa été un objectif de ce travail, il n’a pas été question de procéder à un ni-vellement par le bas. L’outil développé utilise donc quand cela est possiblele langage HTML5 développé par le consortium W3C qui a pour ambitiond’être le futur du Web en y apportant des fonctionnalités qui sont ou se-ront gérées nativement par les navigateurs récents ou futurs. Enfin, il meparaît également intéressant de souligner que l’application a été développéeentièrement à partir d’outils gratuits et open-source.

7

Chapitre 2

Choix stratégiques

Dans ce chapitre, il sera longuement discuté des choix stratégiques quiont été réalisés pour mener à bien ce travail. Il m’a paru important d’yconsacrer un temps conséquent car si les choix entrepris se veulent êtreefficaces, cela pourrait conduire à une application dont la maintenance et lapérennité seraient renforcées. Ainsi, les sections de ce chapitre sont le résultatde différentes choix comme la plateforme d’exécution, les technologies, lesoutils et méthodes de développement, le design avec des fonctionnalités debase et enfin les fonctionnalités additionnelles à intégrer. Pour chacune deces sections, des comparaisons seront effectuées avec un regard critique ainsiqu’une analyse utile pour prendre les bonnes décisions.

2.1 Plateforme d’exécutionLa plateforme choisie a été le World Wide Web, plus simplement appelée

le Web. Avant de discuter de la raison de ce choix, il est intéressant derappeler ce à quoi il fait référence.

2.1.1 Définition du Web

Le Web peut se définir comme étant un système hypertexte public fonc-tionnant sur Internet qui permet de consulter, avec un navigateur, des pagesaccessibles sur des sites à l’aide d’un navigateur connecté à Internet (Wiki-pedia). Inventé en 1989 par Tim Berners-Lee, il est constitué de trois piliersque sont

– les adresses Web (URI pour Uniform Resource Indentifier) qui per-mettent de représenter de manière simple et textuelle les endroits vir-tuels accédés par l’utilisateur.

– le protocole client - serveur HTTP (Hypertext Transfer Protocol) dela couche application du modèle OSI qui définit la manière dont unnavigateur envoie des requêtes à un serveur afin que l’utilisateur final

8

accède au contenu se trouvant sur le serveur et puisse également enenvoyer.

– le langage HTML (Hypertext Markup Language) est le format desdonnées qui permet au navigateur de représenter visuellement ce quel’auteur de la page Web a souhaité faire représenter.

Aujourd’hui, le HTML a pour principal but de définir sémantiquement lecontenu et dans un moindre mesure la manière de le représenter. Ce sont lesfeuilles de style CSS (Cascading Style Sheets) arrivées dans les années 2000qui définissent plus exactement la manière de représenter le contenu. Il y adonc une séparation entre la structure d’un document (HTML) et son stylede présentation (CSS). Cela a de multiples bénéfices comme une diminutionde la bande passante utilisée car une feuille de style est bien souvent dansun fichier à part et mis en cache par le navigateur. Mais aussi, cela conduit àune meilleure intégration d’un contenu. Il suffit de changer de feuille de stylepour que ce même contenu apparaisse différemment. C’est un critère qui acontribué au choix du Web pour développer l’outil de ce mémoire car celaconduit à le rendre intégré de manière simple et complète à la plateformeClaroline.

Avec le HTML et le CSS, il faut rajouter une petite touche magique qu’estle Javascript, langage de programmation créé en 1995 par Brendan Eichet qui n’a cessé d’évoluer avec le temps. Le Javascript est donc du codesource qui peut être interprété par le navigateur du client. Cela permetde créer des pages interactives et ce notamment grâce à une gestion d’ungrand nombre d’évènements liés par exemple à la souris (appuyée, relâchée,déplacée, ...), ou au clavier. Le Javascript peut être utilisé pour modifierle contenu, sa structure ou son style de présentation dynamiquement aprèsque la page Web ait été chargée. Grâce notamment à l’AJAX (AsynchronousJavaScript and XML), il est même possible que Javascript lui-même réalisedes connexions à un serveur. Les avantages de Javascript ont aussi été uncritère clé dans le choix de cette plateforme pour développer l’outil.

De plus, le Web a bien évolué depuis 1989 et Tim O’Reilly a proposé en2005 de le qualifier de Web 2.0 en considérant le Web comme une plateformeà part entière où l’utilisateur devient un véritable acteur dans son expériencesur le Web et où les sites tendent à se rapprocher des applications natives.C’est ce que Dan Farber (éditeur en chef de CBS Interactive News) a qualifiéde Web 2.5.

Le Web, c’est aussi une balise object qui permet de lire et exécuter ducontenu via des plugins comme les logiciels Flash Player d’Adobe, Silverlight

9

de Microsoft ou encore Java de Sun (Oracle) qui ont évolué avec le tempspour proposer des services interactifs en ligne dans le navigateur.

Mais le Web continue lui aussi d’évoluer et ce notamment grâce au W3C(World Wide Web Consortium) présidé par Tim Berners-Lee, l’inventeurdu Web. C’est ainsi que le langage HTML5, toujours en développement,apporte une nouvelle dimension au Web en introduisant de nouvelles ba-lises au langage HTML et de multiples API utilisables par Javascript. Celava permettre de faciliter grandement le développement d’applications Webinteractives.

2.1.2 Applications Web comparées aux applications natives

Après avoir défini brièvement ce qu’était le Web, ce qu’il est et ce qu’ildevrait être dans les années à venir et après avoir manifesté un intérêt pourle développement de l’outil sur cette plateforme, il convient de confronterce choix par rapport aux choix classiques des applications natives dans deslangages comme le C, C++ ou Java et d’observer le comportement actueld’un utilisateur sur son ordinateur.

Ainsi, on peut remarquer que pour beaucoup d’utilisateurs, le naviga-teur représente l’application bien souvent la plus utilisée sur un systèmed’exploitation. Même la gestion des courriers électroniques se déroule pourbeaucoup dans un navigateur, que ce soit via Gmail, Hotmail ou d’autresmessageries électroniques. Google développe d’ailleurs pour la fin de l’année2010, un nouveau système d’exploitation baptisé Chrome OS (sur base duprojet open-source Chromium OS) où le navigateur constitue la seule vraieapplication du système d’exploitation. Ils prévoient cependant l’utilisationde logiciels classiques en les rendant accessibles comme une application Web,c’est-à-dire lisibles dans un onglet de ce navigateur en mode Cloud (les don-nées se trouvent sur un serveur distant) afin d’assurer la transition pourl’utilisateur habitué à ses applications natives.

L’intérêt d’un outil développé pour le Web, outre son accessibilité sur ungrand nombre de plateformes et de systèmes d’exploitation, c’est le fait quel’utilisateur ne doit rien installer de particulier sur sa machine. Il se connecteau site et est directement plongé dans son application. En étant connecté àInternet, cela permet que des calculs importants puissent être exécutés sur leserveur où se trouve l’application Web, ce qui conduit à réduire l’utilisationde ressources sur la machine de l’utilisateur. L’utilisateur ne doit plus mettreà jour l’application, celle-ci se mettant à jour d’elle-même étant donné qu’elleest hébergée sur un serveur distant.

10

D’un point de vue statistique, le Web des applications tend à prendre del’importance d’année en année. Il existe aujourd’hui des applications commeGoogle Docs (éditeur de documents, tableaux, présentations, dessins, ...),Picnik (éditeur de photos), Audiotool (outil de création de musique) ou en-core Youtube Video Editor (outil de montage vidéo) qui reproduisent demanière efficace des logiciels classiques mais qui ont l’avantage d’être to-talement intégrés dans le navigateur, de ne demander aucune installationparticulière à l’utilisateur, d’être accessibles quelque soit l’ordinateur surlequel se trouve l’utilisateur, d’être mis à jour régulièrement sans que l’uti-lisateur n’ait à redémarrer sa machine ou son application et enfin d’utiliserau minimum les ressources de la machine de l’utilisateur. Ces avantages sontassez importants et le monde de l’entreprise tend aussi à utiliser des appli-cations Web. Un bel exemple est le logiciel open-source Open ERP, créé en2002 par un ancien étudiant de l’Université Catholique de Louvain, FabienPinckaers, qui rencontre aujourd’hui un franc succès auprès de nombreusesentreprises. Même s’il existe une version logiciel à installer, il y aussi laversion Web qui reprend les différents avantages donnés plus hauts.

Une remarque souvent prononcée à tort est la nécessité d’Internet pourque l’application soit opérationnelle. Ce n’est pas tout-à-fait correct car ilest possible de créer une version hors ligne qui se synchronise dès qu’uneconnexion à Internet a été trouvée. C’est le cas de GMail qui par l’intermé-diaire d’un plugin (Google Gears) permet l’accès aux courriers électroniquesreçus précédemment et ce même hors connexion. Tout cela reste dans le na-vigateur et présenté exactement de la même façon que lorsque l’utilisateurest connecté à Internet. De plus, le langage HTML5 est doté d’une API pourles applications hors-ligne. Notons que cette remarque est générale et nonliée à l’outil développé dans le cadre de ce travail de fin d’études. En effet,le but de l’outil est permettre à des réunions de se dérouler en ligne, ce quirend ainsi inutile une utilisation de l’outil en mode hors-ligne.

Une autre critique à l’encontre des applications Web qui est elle bien fon-dée est la perte de contrôle de l’utilisateur. Celui-ci ne possédant plus rienou très peu sur sa machine, il devient tributaire du fournisseur de l’appli-cation. Un problème technique chez l’hébergeur de l’application pourraitcouper l’accès à l’utilisateur si le mode hors-ligne est inexistant ou incom-plet. De même, la question de la vie privée intervient aussi puisque desdonnées personnelles peuvent être amenées à transiter sur les serveurs dufournisseur de services. Il faut néanmoins reconnaître que cela est parfoisinhérent à l’application, comme c’est le cas d’un client Web de messagerieélectronique.

11

Après avoir soulevé les avantages et désavantages de l’utilisation du Webpour des applications, c’est donc le choix du Web qui a été utilisé pour ledéveloppement de l’outil car les avantages l’ont emporté sur les désavantages.Cet outil est donc totalement intégré dans le navigateur et ne nécessitepas la moindre installation d’un logiciel en particulier. De plus, cela a lebénéfice supplémentaire de le rendre totalement intégré dans la plateformeWeb Claroline. Le rendu graphique de l’outil tel que les couleurs des textes,la police d’écriture ou encore la taille de ces textes, de même que la couleurdes bordures des cadres ou celle du fond de la page sont celles choisies parClaroline ou par l’université ou l’école qui utilise Claroline si l’interface a étémodifiée. C’est donc pour accroître l’accessibilité et la facilité d’utilisationde l’outil ainsi que son intégration à la plateforme Claroline que le Web aété choisi stratégiquement pour être le moteur d’exécution de l’outil côtéclient. Ce choix étant fait, il y en a bien d’autres qui ont suivi à commencerpar le choix technologique car le Web est un choix de plateformes mais ilexiste plusieurs moyens de développer pour le Web comme énoncés plus haut.La prochaine section sera donc consacrée aux choix quant à la technologieutilisée ou plutôt aux technologies utilisées pour développer l’outil.

2.2 Technologies utiliséesTout d’abord, il est important de mentionner qu’il faut bien distinguer

les technologies utilisées côté client de celles utilisées côté serveur. La raisonde cela est qu’il est fondamental que les utilisateurs aient un accès simple,rapide et direct à l’application alors que pour le serveur, l’installation d’ou-til supplémentaires n’est généralement pas un souci dans la mesure où lestechnologies utilisées pour le serveur restent tout de même compatibles auminimum sur Windows, Linux et Mac OS. De même, imposer la mise à jourde composants ou logiciel du système d’exploitation pour le serveur est bienmoins contraignant que de l’imposer à chacun des utilisateurs de l’applica-tion. Ainsi, l’outil réalisé est pour la partie serveur compatible au minimumavec les trois systèmes d’exploitations cités plus haut moyennant certainesconditions tout-à-fait acceptables. Quant à la partie client, celle-ci est totale-ment compatible pour des utilisateurs sous Internet Explorer 6 comme pourdes utilisateurs sur des navigateurs récents. L’outil cherchant à prendre lemeilleur de ce que la machine du client lui offre comme possibilités, il n’y aaucun nivellement par le bas. De plus, aucune installation particulière n’està effectuer sur la machine du client pour utiliser l’outil.

Ce chapitre se veut être une post-introduction et restera volontairementen surface. Les chapitres suivants commenceront ainsi par une explicationplus détaillée concernant les choix technologiques et des comparaisons plusapprofondies par rapport à d’autres solutions (notamment pour la vidéo-

12

conférence). Les deux sous-sections qui suivent sont donc introductives etse concentrent pour la première sur les technologies utilisées côté serveur etpour la seconde, sur les technologies utilisées côté client.

2.2.1 Technologies utilisées côté serveur

Avant d’annoncer les choix qui ont été pris, il convient d’expliquer toutd’abord pour quelle raison il a été choisi d’utiliser le modèle client - serveuret non le modèle du pair à pair (P2P) où le serveur ne jouerait alors qu’unrôle de mise en liaison des clients. La raison est que le nombre de personnesparticipant à une réunion est bien souvent supérieur à deux. Le modèle dupair à pair peut très bien fonctionner avec plus de deux clients mais celasignifie que chaque client doit envoyer ses données autant de fois qu’il y ad’autres clients connectés. Pour du texte ou la communication d’actions surun tableau blanc, cela n’est pas trop dérangeant si le nombre de clients resteraisonnable (une dizaine maximum). Par contre, pour la vidéoconférence,c’est difficilement envisageable, notamment dû à l’asymétrie des vitesses deconnexions qui pour accroître la vitesse de téléchargement réduit drastique-ment la vitesse d’envoi. A côté de ces limitations techniques, il y a aussil’avantage du serveur pour jouer un rôle à part entière dans la réunion. Lechapitre sur la vidéoconférence expliquera ainsi comment le serveur joueun véritable rôle d’arbitre dans les images à diffuser en priorité. Enfin, ilest pratique pour un participant d’observer la réponse du serveur car celadonne une idée de ce que les autres participants voient au même instant dufait que le serveur envoie les données quasiment en même temps à tous lesclients et que les vitesses de téléchargement sont bien souvent assez élevées.

Voici à présent les technologies utilisées pour le serveur :

– PHP Langage de programmation open-source très popularisé pourle Web et utilisé par de grandes sociétés comme Facebook (premiersite en terme d’audience), il est aussi le langage de la plateforme d’e-learning Claroline. L’intégration de l’outil dans Claroline a donc étésimplifié du fait de l’utilisation du même langage de programmation.Dans l’outil développé, il permet en plus de l’intégration à Clarolinede générer du code HTML répétitif au moyen de fonctions. Cela évitedonc la duplication de code qui nuit grandement à la maintenance d’unsystème. Mais PHP est aussi utilisé comme serveur à part entière, àlancer en ligne de commande, pour la communication client - serveurlorsque l’application a été lancée. Le chat texte par exemple utilisece serveur en PHP. Le client lui envoie un message et le serveur leréplique à tous les clients qui le voient sans avoir dû recharger la pageWeb sur laquelle ils étaient.

13

La compatibilité est assurée étant donné que PHP peut être exécutéavec Apache et est ainsi utilisable sur de multiples systèmes d’exploi-tation. Par contre, l’outil est implémenté en utilisant, tout commeClaroline, la cinquième version de PHP et son modèle orienté objet.

– Neko VM Un autre langage de programmation open-source a été uti-lisé pour la gestion de la vidéoconférence côté serveur. Il contient unemachine virtuelle que l’auteur qualifie de très légère et très optimisée,ce que les tests réalisés ont en effet démontré. Cependant, la partie lo-giciel en Neko pour la gestion serveur de la vidéocnférence n’a pas étédéveloppée par l’auteur de ce mémoire. Le choix de ce langage avec samachine virtuelle sera expliqué plus longuement dans le chapitre dédiéà la vidéoconférence.

Pour ce qui est de la compatibilité, elle est annoncée sur Windows,Linux et Mac OS. Son installation ne requiert rien en particulier surla machine du serveur.

2.2.2 Technologies utilisées côté client

Choisir une technologie côté client n’est pas toujours simple dans la me-sure où le développeur cherche à la fois à atteindre un grand nombre si pasla totalité des personnes souhaitant utiliser l’application et dans le mêmetemps, il cherche à fournir la meilleure expérience utilisateur possible à cespersonnes. C’est pourquoi l’interopérabilité entre plusieurs technologies aété un objectif dans ce mémoire. Voici donc les technologies utilisées, dansquelles situations elles le sont et pour quelles parties de l’application ellessont dédiées.

– Javascript Langage de programmation utilisé sur pratiquement tousles sites Web, il définit clairement la manière d’interagir avec l’utili-sateur lorsqu’il est connecté à l’application. Celui-ci est donc utilisétrès largement dans l’outil et couvre la majeure partie de son com-portement de l’application sur la machine du client. Néanmoins, leJavascript sans les API du futur langage HTML5 ne permet pas defournir l’ensemble des services attendus dans cet outil de réunions enligne. De même que certains services comme l’utilisation de la Web-cam de l’ordinateur de l’utilisateur n’ont pas encore d’API utilisables.

La compatibilité est assurée au minimum sur les trois grands mo-teurs de rendus, qu’il s’agisse de Gecko (moteur de rendu de FireFox),Webkit (moteur de rendu de Safari et Google Chrome / Chromium)et de Trident (moteur de rendu d’Internet Explorer). Des tests ont étéeffectués sur différentes versions de ces navigateurs dont Internet Ex-

14

plorer 6. Même si d’autres navigateurs n’ont pas été testés, le fait derespecter les standards est de bonne augure pour un fonctionnementadéquat sur toutes les plateformes.

– Adobe Flash Technologie actuellement controversée, elle a cependantété utilisée dans ce mémoire. Ce paragraphe a pour but d’apporter unejustification quant à son utilisation. Il est vrai que Flash ne fait paspartie intégrante du Web, c’est un plugin qui s’exécute côté client dansune machine virtuelle, le Flash Player. A ses débuts, il était destinéà la création d’animations vectorielles complexes et aujourd’hui il ap-paraît soit comme un sorte de rustine à l’HTML4 pour étendre sesfonctionnalités, soit en remplacement du langage HTML pour les sitesdits full-Flash. C’est le premier choix qui a été pris pour ce mémoireafin justement de laisser la possibilité à l’HTML5 de prendre les fonc-tionnalités gérées par Flash. C’est ce que fait habilement Google avecGmail (Flash utilisé pour l’upload multiple), Youtube (Flash commelecteur vidéo), Google Traduction (Flash comme lecteur audio pourla synthèse vocale), Google Finance et Analytics (Flash pour les gra-phiques) mais aussi Google Street View (Flash pour la visite virtuelleà 360 degrés). Les possibilités de Flash sont aujourd’hui très nom-breuses et c’est avec un taux de pénétration proche des 98% 1 queFlash a acquis une popularité grandissante sur le Web avec 80% des100 sites les plus visités qui l’utilisent. Flash est souvent critiqué pourses performances mais comme n’importe quel programme, cela dépendfortement de la personne ou de l’équipe qui a créé l’application. Uneautre critique vient du fait que Flash est une technologie propriétaire.C’est en effet vrai mais il faut relativiser cela avec les différentes pos-sibilités de créer et de lire du Flash qui existent, et qui se veulent ac-ceptées par Adobe en utilisant bien souvent les spécifications fourniesofficiellement comme le dit Adobe dans une page Web créée notam-ment pour répondre aux critiques de Steve Jobs : The core engine ofFlash Player (AVM+) is open source and was donated to the MozillaFoundation, where it is actively maintained. The file formats suppor-ted by Flash Player, SWF and FLV/F4V, as well as the RTMP andAMF protocols are freely available and openly published. Anyone canuse the specifications without requiring permission from Adobe. Thirdparties can and do build audio, video, and data services that competewith those from Adobe. Ce sont ces différents éléments qui m’ont aidéà prendre la décision d’utiliser cette technologie.

1. Source : http://www.adobe.com/products/player_census/flashplayer/version_penetration.html et statistiques entemps réel sur http://www.riastats.com/

15

Mais même si Flash dispose de nombreuses qualités, le langage HTML5a un avantage supplémentaire. Outre le fait qu’il soit un format totalementlibre, il revient à différencier les équipes qui déterminent les spécificationsde celles qui les implémentent dans les navigateurs. Cela conduit a séparerles responsabilités et permettre un accès plus large au contenu. En effet,une équipe peut se concentrer à une plateforme en particulier pour implé-menter au mieux les spécifications sur cette plateforme. L’implémentationsur une plateforme ne dépend pas des intérêts commerciaux d’une sociétémais des intérêts de personnes souhaitant contribuer à cette plateforme. Deplus l’avenir de cette technologie est régi par le W3C qui est composé depersonnes émanant de différentes sociétés, ce qui évite le contrôle de la partd’une seule société.

Néanmoins, depuis juin 2009, Adobe a décidé de rendre public les spécifi-cations de Flash Player. C’est ainsi qu’Alessandro Pignotti a pu développerdans le cadre de son travail de fin d’études une version open-source de Flashà destination de Linux, qu’il a nommée Lightspark[30]. Il continue aujour-d’hui son travail et a été rejoint par plusieurs contributeurs. Le support deYoutube est déjà opérationnel et il annonce une exécution jusqu’à deux foisplus rapide par rapport à la version délivrée officiellement par Adobe. Unedes raisons de cela est qu’Adobe, société commerciale, alloue ses ressourcespréférentiellement sur les systèmes d’exploitations les plus utilisés et en par-ticulier Windows. Des tests ont d’ailleurs montré que sur Windows, Flashétait plus performant que HTML5 pour la lecture de vidéos au format H264et ces mêmes tests ont montré l’inverse sur Mac OS. Malgré tout, Flash restefonctionnel sur Mac OS, Linux et Solaris que ce soit via le plugin délivrépar Adobe ou via des versions alternatives tel Lightspark actuellement endéveloppement.

Mais il faut admettre que HTML5 suscite plus d’intérêt et des projetstel que Lightspark existent pour HTML5 en nombre conséquent, il s’agitdes multiples moteurs de rendus existants où différentes équipes travaillentà l’implémentation de l’HTML5 sur ces moteurs. Pour toutes ces raisons,l’auteur de ce mémoire est très favorable au développement de l’HTML5 etaux applications Web qui peuvent ou pourront en tirer parti. Cependant,lorsque l’utilisateur ne dispose pas d’un navigateur implémentant des APIrequises pour l’application ou que l’application a besoin de fonctionnalitésnon prises en compte par l’HTML5, le choix de Flash reste un très bonsecond choix et en particulier car ce dernier communique simplement etrapidement avec Javascript. C’est d’ailleurs toute l’architecture même del’outil développé pour ce mémoire qui repose sur ce fait, Flash peut appelerdes fonctions Javascript tout comme Javascript peut appeler des fonctionsen Flash (Actionscript). C’est la clé de l’interopérabilité réalisée dans ce

16

travail entre Flash et HTML5 (au sens de ses nouvelles API) qui ouvre laporte de l’accessibilité à près de 100% des utilisateurs.

2.3 Outil et méthodes de développementAprès avoir expliqué les raisons du choix de Javascript et de Flash, il y

a un outil qui fût utilisé assez largement dans ce mémoire et il me sembleimportant de lui consacrer la majeure partie de cette section. Cet outil a eneffet conduit à augmenter de manière significative la productivité. Celui-cise dénomme HaXe[32] et est un projet open-source et gratuit inventé parNicolas Cannasse en 2005 pour la société Motion-Twin dont il fait partie.Cette société française s’est focalisée principalement sur des jeux en lignesur le Web en Flash ou Javascript mono ou multi-joueurs.

2.3.1 HaXe comme outil de développement de la partie client

HaXe 2 se veut être un langage universel pouvant répondre à de multiplesbesoins, il est multi-plateformes. Avec une syntaxe proche du Java (plusexactement de l’Action Script 3), il permet de produire du code en Flash,Javascript, PHP, C++ et Neko VM, machine virtuelle créée par le mêmeauteur que HaXe permettant entre autres de développer la partie serveurd’applications. Outre le fait de n’avoir qu’une seule syntaxe pour plusieursplateformes, il intègre une bibliothèque standard complète avec par exempleles dates, tables de hachage, gestion du XML, traitement des chaînes decaractères ou encore les fonctions mathématiques. Mais il contient aussi desbibliothèques spécifiques à chaque plateforme, ce qui évite ainsi le nivelle-ment par le bas en permettant à un programme d’utiliser toutes les possibi-lités offertes par la plateforme vers laquelle il est prévu. Dans le cadre de cemémoire, ce langage a été utilisé pour la production du code en Javascript eten Flash, les deux technologies utilisées conjointement pour la partie clientde l’outil développé.

La production du code en Javascript se traduit par un fichier .js auto-généré à partir d’un ou plusieurs fichiers en HaXe (.hx). Ouvrir le fichierJavascript permet de se rendre compte que le code produit automatiquementest parfaitement lisible et compréhensible par un humain, le compilateur deHaXe se charge de cela aussi en le réindentant. L’utilisation du compilateurde HaXe permet en plus de détecter à priori bon nombre d’erreurs s’il enexistait. Enfin, il faut souligner que HaXe ne ferme pas de portes, il est eneffet tout-à-fait possible d’ajouter du code Javascript directement dans lecode HaXe lorsque le développeur estime qu’il en a le besoin.

2. Site officiel de HaXe : http://www.haxe.org

17

Quant à l’utilisation pour produire du Flash, c’est cet usage qui est le plusutilisé en HaXe et reconnu mondialement. Même Adobe le cite ouvertementsur sa page en réponse à Steve Jobs : Finally, the Flash Platform has a richdeveloper ecosystem of both open and proprietary tools and technologies, in-cluding developer IDEs and environments such as FDT, IntelliJ, and haXe.Le compilateur de HaXe peut soit générer un fichier Actionscript, langagesource de Flash, soit générer directement un fichier compilé .swf. A la dif-férence de Javascript qui est interprété par le navigateur, Flash est compiléet exécuté par une machine virtuelle, cela explique que HaXe peut au choixjouer le rôle d’intermédiaire ou reprendre toute la chaîne en créant du codecompilé et directement exécutable. Dans ce mémoire, c’est le second choixqui a été pris car le compilateur de HaXe offre des performances qui surcertains programmes conduit à une compilation jusqu’à sept fois plus rapideque le compilateur mxmlc d’Adobe 3. Quant à la compilation de l’outil réa-lisé, le temps nécessaire pour l’ensemble de la partie client était en effet trèsrapide. En plus d’être plus rapide à la compilation, c’est aussi à l’exécutionque HaXe se distingue pour produire du Flash. Un test réalisé sur l’anima-tion de figures fractales montre des performances doublées sur une versionen Actionscript 4. Il est d’ailleurs intéressant de remarquer que l’auteur de cetest a pu améliorer considérablement les performances 5. Cela montre bienque Flash peut se révéler très efficace et que comme pour tout langage, c’estavant tout l’ingénierie des méthodes utilisées qui affecte les performances.

Le langage HaXe en lui-même reprend un concept bien connu en C sousle noms de macros. Pour rappel, il s’agit de variables ou de fonctions dontchaque appel dans le code se verra remplacé à la compilation par respective-ment la valeur de la variable ou le code de la fonction. En HaXe, il suffit deplacer le mot-clé inline dans la définition d’une variable ou d’une fonctionafin de reproduire cet effet. L’avantage de cette technique est qu’elle permetde garder un code d’origine propre avec une architecture logicielle solideoù le programme est intelligemment découpé en fonctions tout en obtenantdes performants accrues dans le cas où le même code doit être réexécuté denombreuses fois.

Bien d’autres choses pourraient être dîtes sur ce langage comme l’apportde multiples contributeurs dans haxelib, le portage vers Java, le HaXe pouriPhone ou encore le projet Neash (NEko-flASH) visant à porter automati-quement du code destiné pour Flash vers Neko et d’autres plateformes. Ce

3. Le test sur la vitesse de compilation de code HaXe :http://ncannasse.fr/blog/getting_some_numbers

4. Le test sur la vitesse d’exécution de HaXe pour Flash :http://www.splashdust.net/2009/10/as3-vs-haxe-performance/

5. Le test ci-dessus avec optimisations :http://www.splashdust.net/2009/11/bitmapdata-and-palettemap/

18

qui est cependant à rappeler, c’est que la partie serveur de la vidéoconfé-rence est du code HaXe pour Neko VM qui a été implémenté par NicolasCannassse, l’auteur de HaXe. La première annexe de ce mémoire comported’ailleurs une partie d’une interview qu’il a donnée au magazine italien Pro-grammo en juin 2009.

2.3.2 Bibliothèques et format de données

Ce mémoire utilise aussi une bibliothèque libre bien connue pour Ja-vascript qui est JQuery. Celle-ci permet de simplifier grandement certainesopérations, notamment des modifications du DOM (Document Object Mo-del), la gestion des évènements ou encore la manipulation des feuilles destyle (CSS). C’est précisément ces trois usages qui ont été utilisés pour l’ou-til réalisé. Une remarque intéressante est que non seulement JQuery simplifiedes opérations mais il permet aussi une compatibilité avec un grand nombrede navigateurs, Internet Explorer 6 compris. Il est à noter que Claroline,la plateforme d’e-learning pour laquelle l’outil est destiné, utilise égalementJQuery.

D’autres bibliothèques sont utilisées pour différents usages. Il y a parexemple Explorer Canvas, créée par Google, qui permet d’émuler la baliseCanvas du langage HTML5 ainsi que ses API de dessin 2D pour InternetExplorer 6, 7 et 8. La version 9 qui devrait être finalisée pour la fin 2010le gèrera nativement. Cette bibliothèque que l’on pourrait qualifier de com-patibilité n’est chargée que si nécessaire bien sûr. Enfin, une toute petitebibliothèque getPos a été utilisée car elle permet d’identifier de manière pré-cise et sur n’importe quel navigateur la position d’un élément d’une pageWeb en termes de pixels. L’usage de cette librairie sera expliqué dans lesprochains chapitres de ce mémoire.

Cette section sur les technologies utilisées se termine en mentionnant unformat de données qui présente des qualités intéressantes. Il s’agit de JSON(Javascript Object Notation) créée par Douglas Crockford. Dans ce format,l’information représentée est structurée et prend très peu de place. Son butest essentiellement de pouvoir encoder des objets, des tableaux ou encoredes valeurs génériques (entiers, flottants, chaînes de caractères, ...) que l’onretrouve dans un langage de programmation. L’intérêt de son utilisationdans ce mémoire réside dans le fait que dans la communication client -serveur, il y a nécessité de transmettre de l’information et que celle-ci setrouve initialement dans une structure de données. Ainsi, grâce aux fonctionsJavascript et PHP permettant d’encoder ou de décoder le format JSON, ildevient simple et élégant de s’échanger de l’information tout en minimisantla verbosité et donc les données servant à transmettre la structure.

19

2.3.3 Découpage de l’application en différents modules

Ce chapitre a commencé avec une explication relative à la plateformed’exécution, puis c’est le choix des technologies qui a été discuté et enfin,l’utilisation de bibliothèques et d’un format de données. Sachant tout cela,il est à présent temps de parler concrètement du développement même del’outil. Voici comment a été organisé son développement et son architecturelogicielle.

Avec les différents cours suivis et projets réalisés à l’Université Catholiquede Louvain, il convient d’affirmer que le découpage d’un programme à réali-ser en différents modules ainsi que le découpage d’un module en différentesfonctions et classes peut avoir un impact important sur la qualité du résultatfinal. En effet, la décomposition selon les buts à atteindre assure un faiblecouplage, ce qui simplifie les améliorations, l’ajout de nouvelles fonctiona-lités et bien sûr l’identification des problèmes qui pourraient survenir. Lamodularisation a aussi comme avantage de rendre des modules réutilisablespour des programmes futurs.

Figure 2.1 – Découpage de l’application en modules

C’est ainsi que le choix a été pris de créer quatre modules qui sont toutsimplement les noms des quatre prochains chapitres, à savoir la gestion dela communication client - serveur, le tableau blanc collaboratif, la vidéo-conférence et l’intégration dans la plateforme Claroline, comme on peut levoir dans la figure 2.1. Il y a bien un couplage faible entre ces modules. Eneffet, le module de la gestion de la communication a été développé en mêmetemps que le tableau blanc collaboratif. Le tableau blanc peut donc se suffire

20

à lui-même, il perd alors la notion de collaboration. De même que la com-munication n’impose pas le tableau blanc. Le lien entre ces modules n’existedonc que s’il est nécessaire d’avoir les deux dans une même application. Ily a d’ailleurs un chat texte (mini module, non représenté) qui utilise de lamême façon le module gérant la communication. La vidéoconférence a été ra-joutée ensuite mais là encore, elle pourrait être utilisée isolément des autresmodules sans que cela nécessite un travail sur tout le code. Enfin, l’intégra-tion dans Claroline ajoute une dimension supplémentaire à l’outil puisquegrâce à une base de données, il y a une véritable gestion d’un ensemble deréunions. Cette gestion comprend le listage, l’ajout, la modification et lasuppression de réunions. L’accès en ligne se résume à un lien dans le tableaudes réunions, qui donne alors accès une page intégrant les trois moduleset elle-même intégrée totalement dans l’interface de Claroline, de sorte quel’utilisateur se sente en confiance. Dans la figure 2.1, on remarque qu’il y aun lien unidirectionnel car ce module fournit des informations servant auxtrois autres modules que l’on peut regrouper et définir comme super-module.Les trois autres modules n’ont pas besoin de communiquer avec le moduled’intégration à Claroline. Ce mode de fonctionnement permet de pouvoirinclure très simplement cet outil de réunions dans une autre plateforme queClaroline si on en a le besoin.

2.4 Fonctionnalités et interface utilisateurLes choix stratégiques portent aussi sur des fonctionnalités dédiées à l’ap-

plication et sur son interface utilisateur. Celle-ci a en effet un impact puis-qu’elle peut donner lieu à de nouvelles fonctionnalités. C’est donc au seind’une même section qu’elles vont être présentées. Il s’agit ici d’un schéma etde fonctionnalités importantes pour l’outil. Une capture d’écran et un ma-nuel utilisateur se trouvent en annexe et l’explication sur les fonctionnalitésse trouve dans les prochains chapitre. Cette section se veut juste introductivecar c’est elle qui a permis d’avoir un objectif clair à réaliser.

2.4.1 Présentation des fonctionnalités principales

La figure 2.2 présente l’interface utilisateur créée pour cet outil. Il s’agitd’une interface très basique mais pouvant s’adapter automatiquement à lapage Web à laquelle elle est destinée. Ainsi, la couleur d’arrière-plan ou celledes cadres et textes, de même que la taille de ces éléments provient de lafeuille de style CSS globale pour le site. Dès lors, lorsqu’il fût intégré dansClaroline, les bordures des cadres étaient grises car Claroline a choisi cettecouleur par défaut pour l’ensemble de la plateforme. Il en va de même pourla couleur d’écriture ainsi que la police. Enfin, si l’équipe de Claroline ou ungestionnaire de celle-ci souhaite réaliser des modifications de design, il luisuffira d’éditer le fichier CSS.

21

Figure 2.2 – Schéma de l’interface utilisateur avec 10 participants

Le lien entre l’interface et les fonctionnalités apparaît avec les trois cadresdu haut. Ceux-ci étant de taille supérieure aux huit cadres sur les côtés. Laraison de cela est que le premier cadre, centré sur la page, est celui réservéau tuteur ou professeur encadrant la réunion. Sa position dans la page aété pensée pour que l’image des participants soit un profil de face avec lesyeux dirigés vers le centre, étant donné que le professeur occupe le rôleprincipal d’une réunion. Ensuite, il y a à sa droite deux grands cadres, ilssont dédiés aux étudiants ou autres participants. Il y a donc deux places dîtesprivilégiées (de taille plus grande, mieux placée sur l’écran) et huit placesstandard. Cela reflète une fonctionnalité qui consiste à doter le systèmed’une petite intelligence artificielle qui va décider qui doit être placé dansun cadre du haut et quand. Cela se base sur le microphone de manière àmettre en avant les personnes qui prennent la parole tout en essayant à lafois d’obtenir une certaine équité entre les participants et d’éviter de fairedes changements trop régulièrement afin de ne pas perturber les utilisateurs.C’est donc un des exemples qui montre l’intérêt du modèle client - serveurici puisque le serveur joue en quelques sortes un rôle d’arbitre de la réunion.Les détails techniques de cette fonctionnalité seront exposés dans le chapitresur la vidéoconférence.

22

Au milieu de la page Web se trouve donc une grande zone pouvant conte-nir des slides que le créateur de la réunion aura préalablement renseignés.Cette zone fait aussi office de tableau blanc collaboratif. C’est donc une zonemixte où l’on peut dessiner sur les slides ou sur des pages blanches selon lemode sélectionné. Afin de rendre cela pratique, il y a deux compteurs indé-pendants, l’un pour le numéro du slide en cours et l’autre pour le numérode la page blanche en cours. A tout moment, il est possible de basculer d’unmode à l’autre d’une simple pression sur une touche du clavier. Il est doncpossible d’être en train de discuter du slide 4 puis d’esquisser un schéma surune page blanche et de revenir au slide 4, et cela très simplement.

Outre le dessin et la vidéoconférence, un petit outil supplémentaire nomméDisplayer a été intégré dans le tableau blanc. Il permet de montrer aux autresutilisateurs la position actuelle de votre souris sur l’écran. L’intérêt est depouvoir discuter d’une partie d’un schéma comme si on était physiquementprésent, c’est-à-dire en montrant avec son doigt ou plus exactement dans laversion virtuelle avec sa souris. En effet, il y a le son, la vidéo, les slides etle dessin mais il manquait le laser, la baguette ou tout simplement le doigtpour identifier une partie d’un slide ou d’un schéma. C’est donc un outil quim’a semblé fort utile pour combler un manque dû à la virtualisation de laréunion.

2.4.2 Modélisation de l’activité d’un client

Une autre fonctionnalité qui m’a semblée nécessaire d’ajouter à cet outilest de montrer aux autres utilisateurs les clients actuellement actifs dans laréunion. Il convient d’apporter une définition d’un client actif, et il s’agitici d’un participant qui à un moment donné démontre sa présence vis-à-visdes autres participants. Concrètement, cela comporte dans l’outil développédeux évènements, le fait de dessiner et le fait de parler. Mais, il est importantde modéliser l’activité d’un client pour bien se rendre compte de commenton passe d’un état actif à un état inactif.

La figure 2.3 modélise cette machine à états avec deux états, Client actif etClient inactif. Pour être actif, il suffit de parler ou de dessiner. En revanche,pour devenir inactif, il faut que ces actions conduisant à l’inactivité soientconjointement non pratiquées.

Comme dans bien d’autres parties de l’outil développé, une attention par-ticulière à l’extensibilité a été pensée. Ainsi, tel les trois points de suspen-sions dans la figure 2.3, il est très simple d’ajouter d’autres évènements quirendent le client actif tout en s’ajoutant automatiquement à la liste desévènements contraires qui ensemble rendent le client inactif. Il suffit pourcela de modifier la petite classe MeetingUser en ajoutant une valeur et une

23

Figure 2.3 – Schéma de la machine à état modélisant l’activité d’un client

constante pour ce nouvel évènement. Ensuite, il suffira d’appeler Meeting-sUserInterface.setUserAsActive(clientId, use) où use est la valeur ajoutéedans MeetingUser décrivant ce nouvel évènement, chaque fois que l’évène-ment se produit. Lorsque l’évènement inverse ce produit, il suffit là d’appelerMeetingsUserInterface.setUserAsInactive(clientId, use). Ces deux fonctionseffectuent elles-mêmes la gestion de l’état Client actif / Client inactif, etapportent des modifications visuelles à l’interface (bordure rouge et texterouge pour le client actif). Il est là aussi très simple d’adapter le renduvisuel d’un client actif en ne modifiant que la fonction MeetingsUserInter-face.setUserAsActive(clientId, use).

24

Chapitre 3

Gestion de la communicationclient - serveur

Un outil de réunions en ligne se doit de gérer la communication entre lesdifférents participants de la meilleure manière possible. Il m’est d’avis quec’est même le coeur de l’outil. Il faut que lorsqu’une personne dessine, lesécrans des autres participants ont le dessin qui se trace quasiment à la mêmevitesse que la personne qui le dessine. Il faut donc minimiser la taille desmessages qui transiteront sur le réseau. Il est aussi important de comprendrequ’il s’agit ici d’une communication bidirectionnelle. Un participant peutenvoyer des messages mais il doit aussi pouvoir en recevoir et c’est pourquoiil est préférable d’avoir un canal de communication prévu à cet effet, unsocket, plutôt que d’utiliser l’AJAX (Asynchronous Javascript and XML).La section suivante a donc pour but de comparer ces deux possibilités afinde justifier le choix des sockets. Puis, il sera question d’un protocole pourles sockets, et c’est précisément le nouveau protocole WebSocket du langageHTML5 qui a été choisi. Ensuite, après avoir présenté le petit utilitaire pourles WebSockets, il sera discuté d’une véritable stratégie de communicationsqui a été pensée pour assurer la minimalisation des messages et la facilitéde traitement et d’implémentation. Enfin, le développement effectif de cepremier module, aussi bien côté client que côté serveur sera présenté.

3.1 Etablissement d’une connexion bidirectionnelleLorsque l’on est sur une page Web, il n’y a bien souvent aucune connexion

une fois que le navigateur a terminé le chargement de la page et des fichiersinclus (scripts, feuilles de style, images, animations, etc...). Néanmoins, onpeut voir de plus en plus des connexions de la page Web déjà chargée versun serveur avec une réponse de celui-ci et ce grâce à la technologie AJAX.En effet, le navigateur peut se connecter à un serveur au moyen de l’objetXMLHttpRequest (XHR) en effectuant des requêtes HTTP asynchrones, ce

25

qui lui permet d’envoyer des informations au serveur mais aussi de récolterdes informations qu’il peut par exemple utiliser pour modifier la présentationde la page Web en cours. Un exemple intéressant est le site de vidéos Youtubeoù il est possible de passer d’une page de commentaires à une autre sansdevoir recharger la page Web, ce qui évite une coupure de la vidéo luepar le navigateur. Avec AJAX, c’est uniquement la partie sous la vidéo quise met à jour proprement. Le problème de cette méthode est qu’elle estunidirectionnelle, elle nécessite que le client envoie une requête pour que leserveur lui réponde. Le serveur ne peut pas joindre le client au moment où leserveur en a besoin. Une technique pour résoudre ce problème est appelée lelong polling et fait l’objet de la sous-section qui suit. La suivante discuterade la solution adoptée pour le mémoire, les sockets.

3.1.1 Technique du (long) polling (AJAX)

Figure 3.1 – Modélisaton du polling

Il existe la technique bien connue appelée le polling (attente active) oùle client interroge de manière régulière le serveur afin d’obtenir des informa-tions. En effet, étant donné qu’il ne sait pas quand le serveur les aura, il doitdonc répéter la demande de multiples fois. Cela est illustré dans la figure 3.1où l’on peut voir que les trois premières requêtes ont dans ce cas été inutilescar le serveur n’avait pas encore d’information à communiquer. C’est toutde même le moyen le plus utilisé en AJAX pour des communications client -serveur et c’est d’ailleurs celui employé dans l’outil Discussion de Claroline.Il est d’ailleurs possible d’y configurer le temps de rafraichissement : Timeto automatically refresh the list of messages in user’s view. Each refresh is arequest to your server. Too low value can be hard for your server. Too highvalue can be hard for user. (CLCHAT module, configuration).

26

Le problème est clairement expliqué au gestionnaire de la plateforme. Soit,c’est le serveur qui est abondamment sollicité en recevant des demandesd’informations à répétition, soit c’est l’expérience utilisateur qui est réduiteavec une latence trop forte, de l’information que le serveur possède maisque l’utilisateur ne voit pas. Même si le serveur pouvait avoir une bonneconfiguration et donc permettre plusieurs requêtes par seconde, ce seraitquand même dommage de le faire travailler de manière importante pourrien, ou plutôt pour répondre à chaque client qu’il n’a rien à communiquer.Afin de tenter de résoudre ce problème, une adaptation du polling peut êtreréalisée, il s’agit du long polling.

Figure 3.2 – Modélisaton du long polling

Comme le laisse penser le nom donné à cette technique, elle consiste àeffectuer une requête à un serveur et laisser ce dernier répondre que lorsqu’ila quelque chose à communiquer au client ou après un certain délai. Il y adonc pour le client une attente de réponse à la requête qui devient bienplus grande que lors d’une requête normale, laissant penser au navigateurdu client que le serveur est difficilement joignable. C’est ce que l’on peutremarquer sur la figure 3.2 où l’on observe que le délai de réponse a étédépassé pour la première requête, le serveur a alors répondu avec une absenced’information. La seconde requête a elle un retour d’information après unecertaine attente. Le fait qu’il s’agisse de requêtes asynchrones (AJAX pourAsynchronous Javascript and XML) évite heureusement que l’utilisateursoit bloqué dans la page Web qu’il est en train de lire lors de l’attente deréponse du serveur. Cela revient donc à maintenir artificiellement un lienentre le client et le serveur en tentant d’avoir le même effet qu’une véritableconnexion bidirectionnelle persistante entre le client et le serveur.

Il y a néanmoins plusieurs problèmes qui se posent toujours.

27

– le nombre de connexions entre un client et le serveur est élevé. Il enfaut tout d’abord une ayant pour but de réceptionner des messages,puis une nouvelle chaque fois que le serveur répond au client.

– Chaque message inclut un entête HTTP, ce qui dans une applicationclient - serveur peut être considéré comme de l’overhead, autrementdit ici de l’information inutilement répétée plusieurs fois.

– Il y a un travail supplémentaire à effectuer côté client pour assurer à lafois la réception des réponses aux requêtes envoyées et l’envoi de nou-velles requêtes, et ce car le serveur ne peut attendre trop longtempsavant de répondre sinon la requête serait considérée comme non abou-tie. Il y aura donc toujours des réponses vides comme dans le pollingclassique(c’était le cas dans la figure 3.2), mais normalement en moinsgrande quantité. Le script client se doit donc de traiter correctementces différentes connexions.

Pour l’outil développé dans le cadre de ce mémoire, une attention parti-culière à ce problème fût portée. En effet, la virtualisation classique doit sefaire dans les meilleures conditions possibles et ne peut se permettre d’inter-roger abusivement un serveur. Une alternative à ces techniques de pollingsont les sockets, dont leur intérêt est présenté dans la prochaine sous-section.

3.1.2 Utilisation de sockets

Figure 3.3 – Modélisaton des sockets

L’intérêt d’utiliser des sockets est que cela permet de créer une connexionpersistante et bidirectionnelle entre deux entités, par exemple un client et unserveur, c’est ce qui est représenté dans la figure 3.3. Il y a en effet une seuleconnexion en full-duplex et non un ensemble de connexions comme c’est le

28

cas avec le polling. De plus, l’établissement de connexion (envoi et réceptiond’un handshake) demande un entête dédié mais une fois la connexion établie,cet entête ne doit plus être inclus dans les messages. Le problème des entêtesHTTP dans chaque message est donc ici évité. Enfin, le script client est trèssimple, il y a principalement une fonction callback qui permet la réceptionde messages et une fonction pour en envoyer. C’est donc vraiment simple àmettre en pratique.

Un test intéressant réalisé par Ericsson Labs [24] montre la différence deréactivité entre un tableau blanc collaboratif utilisant AJAX et le mêmeutilisant les sockets. Ils justifie l’écart de performance par l’entête HTTPpour AJAX qui n’apparaît pas dans WebSocket, entête sur lequel il y a untraitement effectué par le navigateur bien sûr. Une vidéo le montre en action(voir http://www.youtube.com/watch?v=Z897fkPn7Rw).

Le problème des sockets pour le Web est qu’il n’existait pas de manièreréellement simple et standardisée. Le passage par un plugin comme Flashdevenait obligatoire afin d’utiliser ce moyen de communication performant.C’est du passé ou encore du présent selon les navigateurs, mais ce qui estcertain, c’est que le langage HTML5 vient avec une API dénommée WebSo-cket [41], avec le nouveau protocole WebSocket utilisant la couche TCP etétabli par l’IETF (Internet Engineering Task Force) [18].

Notons cependant que l’utilisation de sockets pourrait nécessiter pour leserveur un programme exécuté en permanence et supplémentaire au serveurWeb. Cela est au conditionnel car des équipes de Google travaillant surles projets Chromium sont en train d’implémenter une extension à ApacheHTTP Server pour que celui-ci gère directement les WebSockets HTML5.Au moyen de deux handlers, il est ainsi possible d’éviter que le serveur nefasse que de la simple réplication (voir [38]).

Enfin, il est également à noter qu’il faut que le client accepte une connexionsur l’hôte et le port de l’application. Cependant une configuration standardd’un pare-feu comme Zone Alarm ne provoque pas d’alerte particulière...Quant au réseau utilisé pour se connecter à Internet, il faut aussi que celui-ci accepte des connexions TCP sur l’hôte et le port de l’application.

3.2 Présentation des WebSocket du langage HTML5Après avoir choisi d’utiliser ce mode decommunication, le choix du pro-

tocole WebSocket fût une évidence du fait de l’API du langage HTML5 quifacilite considérablement son utilisation. L’avantage de l’HTML5 et de sa

29

standardisation par le W3C est que les navigateurs l’implémentent native-ment. C’est le cas de Google Chrome / Chromium 4 et Safari 5. Ce serabientôt le cas pour Firefox et Internet Explorer dans leur prochaine version,attendues dans leur version finale pour la fin de l’année 2010 ou début 2011.Concernant les navigateurs qui ne le gèrent pas en natif, le choix a été depasser par Flash, avec la création d’un véritable utilitaire qui pourra servirdans bien d’autres applications demandant une connexion bidirectionnellepersistante. Cette section commence par définir le protocole WebSocket puisexpliquera le développement de cet utilitaire.

3.2.1 Définition du protocole WebSocket

Ce nouveau protocole pourrait à lui seul faire l’objet d’un travail de find’études tant il y a de choses à en dire. Le but ici est donc de définir dansles grandes lignes ce protocole. Il est aussi important de signaler qu’il n’esttoujours pas finalisé à ce jour (juillet 2010) et que des modifications peuventsurvenir. Néanmoins l’état d’avancement est déjà bien conséquent et laissesupposer que le risque de rencontrer une nouveauté qui rendrait incompa-tible les serveurs l’utilisant est relativement faible, même si en mai 2010,une modification importante a été effectuée (voir [19]). Celle-ci modifiait lamanière d’établir une connexion en y ajoutant une sécurisation. Cette modi-fication implique donc une modification de la partie serveur mais permet unserveur hybride traitant ces deux drafts, ce qui est le cas du serveur utilisépour l’outil développé dans le cadre de ce mémoire.

Etablissement d’une connexion

Comme on pourrait s’en douter, c’est le client qui initialise cette connexionbidirectionnelle et ce en envoyant une requête dite de handshake au serveur.Celle-ci ressemble à :

GET /phpWebSocket/server.php HTTP/1.1Upgrade: WebSocketConnection: UpgradeHost: localhost:843Origin: http://localhostSec-WebSocket-Key1: aaaaaaaaaaaaaaaaaaaaaaaaaaSec-WebSocket-Key2: bbbbbbbbbbbbbbbbbbbbbbbbbb

xxxxxxxx

C’est donc ici une requête HTTP en GET qui est envoyée au serveurlocalhost sur le port 843. L’intérêt d’effectuer une requête HTTP est de pou-voir combiner serveur de WebSocket et serveur Web (cf 3.1.2). Les champsUpgrade et Connection indiquent que le but de cette requête est d’établir une

30

connexion utilisant le protocole WebSocket. Concernant le champ Origin, ils’agit du serveur Web qui héberge la page Web sur laquelle la connexion viaWebSocket est effectuée. Le draft 76 a ajouté deux champs Sec-WebSocket-Key1 et Sec-WebSocket-Key2 ainsi que 8 octets à la suite de ces paramètres.Ceux-ci sont des valeurs que le serveur peut utiliser pour construire une cléde 16 octets, l’inclure dans sa réponse et ainsi prouver au client qu’il a bienlu son handshake.

La réponse du serveur à cette requête ressemble à :

HTTP/1.1 101 Web Socket Protocol HandshakeUpgrade: WebSocketConnection: UpgradeSec-WebSocket-Origin: http://localhostSec-WebSocket-Location: ws://localhost:843/phpWebSocket/server.php

yyyyyyyyyyyyyyyy

La clé de 16 octets dans cette réponse ne correspond à rien bien sûr, c’estjuste pour l’exemple. Il y a ici deux nouveaux champs, le premier, Sec-WebSocket-Origin contient l’origine de la requête du client, si et seulementsi, il accepte cette origine. Cela définit une politique de sécurité veillant àdéfinir les clients (via leur origine) qui ont le droit de se connecter au serveur.Le second champ, Sec-WebSocket-Location définit l’endroit où se trouve leserveur WebSocket. On peut y voir la manière d’écriture le protocole dansune adresse : ws://.

Format des messages

Lorsque la connexion a été établie, la connexion est ouverte de manièrepermanente, permettant au serveur comme au client d’envoyer et de recevoirdes messages. Ces messages sont du texte seulement (limitation actuelle duprotocole WebSocket) et ce texte doit être encodé au format UTF-8. Unmessage ne contient que deux octets supplémentaire aux données utiles, ils’agit de 0x00 pour marquer le début d’un message et 0xFF pour marquerla fin d’un message.

Passage des proxys

Le nouveau protocole WebSocket a bien entendu pensé à ce qui pour-rait être problématique, les éventuels proxys. Ainsi, un client WebSocketest capable de détecter la présence d’un proxy et d’automatiquement utili-ser un tunnel pour le passer. Pour ce faire, il envoie une commande HTTPCONNECT au serveur proxy afin de demander la création d’un tunnel per-sistant sur un hôte et port spécifique.

31

Notons que c’est ici une petite introduction à ce protocole. Celui-ci in-troduit d’autres concepts, non-utilisés dans ce travail, que sont par exempleles WebSockets cryptés (wss://) ou les sous-protocoles (protocole au niveauapplicatif).

3.2.2 Présentation de l’API WebSocket du langage HTML5

Afin d’utiliser ce nouveau protocole, une API a été créée par le WorldWide Web Consortium (W3C) [41], et est toujours en développement, bienque la base ait peu changé depuis sa création. Cette sous-section va donc pré-senter cette API et démontrer sa simplicité d’utilisation. Elle est tellementsimple qu’elle tient dans une seule figure, 3.4.

Figure 3.4 – API WebSocket du langage HTML5 (figure reprise de [41])

Cette API se compose donc d’une seule interface WebSocket. Pour initierune connexion, il faut alors créer un objet WebSocket en renseignant auminimum l’URL du serveur, de la forme ws:\\host:post/resource (casd’une connexion non cryptée). La création de cet objet provoque directementl’envoi de la requête de handshake permettant d’établir une connexion.

Pour envoyer un message, il suffit d’appeler la méthode send(msg) enmettant le message en paramètre, sans ajouter les marqueurs du protocole(le navigateur s’en charge). Pour recevoir un message, il suffit là de définirla fonction callback onmessage(event) où event.data contient le messagereçu, sans les marqueurs du protocole.

32

L’API ajoute à cela une méthode close() qui permet au client de fermerla connexion ainsi que trois autres fonctions callback, onconnect(event)appelée dès que la connexion avec le serveur est établie, onclose(event)appelée si la connexion a été coupée et enfin onerror(event) appelée encas d’erreur. A noter que l’API contient en plus d’autres champs, constanteset méthodes pour des utilisations plus spécifiques du protocole, qui ne sontpas utilisées dans l’outil développé dans le cadre de ce mémoire.

3.2.3 Développement de l’utilitaire : Passerelle avec Flash

Note Un raccourci de langage est ici utilisé dans les explications ci-dessous. Javascript est dit pour le navigateur via Javascript, et Flash est ditpour l’animation Flash exécutée dans la page Web.

L’API HTML5 pour le protocole WebSocket n’étant pas disponible sur lesnavigateurs anciens et sur plusieurs navigateurs actuels, il y a un véritablebesoin de combler ce manque afin de rendre l’outil vraiment accessible àtous, quelque soit le navigateur ou le système d’exploitation du client. Lechoix a été pris de développer un véritable utilitaire dont le manuel se trouveen annexe (A). Cet utilitaire rend possible une connexion bidirectionnelle surune page Web à l’aide d’un objet Flash. Il se compose de trois fichiers (deuxJavascript et un Flash) et d’une seule ligne de code HTML à ajouter dans lapage Web sur laquelle on souhaite utiliser les API HTML5. C’est donc unevéritable opportunité pour toute personne souhaitant établir une connexionbidirectionnelle dans une page Web tout en n’utilisant que la nouvelle APIHTML5 et dans le même temps atteindre un taux d’accessibilité qui frôlerales 100%.

D’après les recherches qui ont été effectuées, ce type d’utilitaire n’a pasencore été développé à ce jour, seul un framework (JWebSocket) utilise éga-lement Flash quand cela le nécessite mais il demande de passer par les fonc-tions du framework au lieu de l’API HTML5. L’utilitaire réalisé pour ce mé-moire est lui défini sur base des spécifications de l’API WebSocket HTML5et a ainsi pour avantage que le développeur peut utiliser directement la nou-velle API, en ne devant plus se soucier de la compatibilité avec les anciensnavigateurs.

Fonctionnement de l’utilitaire

Techniquement, il y a donc une ligne de code à ajouter au code HTMLpour que l’utilitaire soit fonctionnelle. Cette ligne de code insère le fichierJavascript WebSocketBridge.js (généré à partir de WebSocketBridge.hx). Lefichier est très léger (16ko) et pourrait même être réduit en le compressantavec les outils adéquats. Le code exécuté va d’abord vérifier si le navigateur

33

dispose de l’API WebSocket HTML5, et seulement si ce n’est pas le cas, ilinsère via une requête synchrone le code inclus dans le fichier WebSocket.js(généré à partir de WebSocket.hx). L’utilisation d’une requête synchrone estnécessaire car le code qui est inclus définit le prototype WebSocket, imitantl’interface WebSocket de l’API HTML5, et doit donc obligatoirement figureravant toute création d’objets WebSocket.

Figure 3.5 – Chargement en cas de détection de l’API WebSocket

Figure 3.6 – Chargement en cas de non détection de l’API WebSocket

Comme il est possible de le constater sur les figures 3.5 et 3.6, le fichierWebSocket.js visant à imiter l’API WebSocket du langage HTML5 ainsique l’animation Flash (FlashWebSocket.swf généré à partir de FlashWebSo-cket.hx) ne sont chargés que si le navigateur n’intègre pas l’API WebSocket.Ce chargement supplémentaire ajoute environ 300 millisecondes au charge-ment de la page, ce qui est encore assez raisonnable.

Lorsque l’API doit être simulée, ce sont donc ces deux fichiers qui sontajoutés. Le fichier Javascript crée donc un prototype WebSocket et reprendla plupart des fonctions de l’API. A la création d’un nouvel objet WebSocket,une animation Flash est alors insérée dans la page Web et est invisible pourl’utilisateur. Flash disposant d’une API permettant la création de sockets, ilest ainsi possible de créer un client Flash pour le protocole WebSocket. Cetravail avait déjà été réalisé en open-source [4], il a donc été utilisé pour cetutilitaire. Il a été converti manuellement en HaXe puis quelques correctionsont été apportées.

34

Garantie d’une bonne communication Flash - Javascript

Le travail réalisé personnellement pour cet utilitaire est donc essentielle-ment la communication entre Flash et Javascript. A partir d’exemples don-nés dans la documentation d’Adobe [34] sur la classe ExtensionInterface,une stratégie a été développée afin d’assurer de manière sûre que la commu-nication entre Flash et Javascript se déroule bien, sans problème. L’exempleétait incomplet, car il s’assurait uniquement que Javascript était prêt à re-cevoir des appels depuis Flash, or l’inverse est vrai aussi. Cependant, il fautreconnaître que l’exemple est juste et sans bug, dans la mesure où Javascriptn’appelle Flash qu’après que la page ait été chargée (interception de l’évè-nement onload dans Body). Ainsi, effectivement, Flash sera toujours chargélorsque Javascript le contactera. Mais l’utilitaire n’ajoutant Flash que lorsde la demande de connexion, il faut aussi prévoir ce cas de figure.

La stratégie adoptée pour une bonne communication entre Flash et Ja-vascript est d’utiliser deux temporisateurs, un en Flash et un autre en Ja-vascript. Flash, une fois lancé, va donc appeler toutes les cinquante milli-secondes une fonction Javascript. Cette fonction lui retourne True et met àjour une variable Javascript certifiant que Flash est bien initialisé dans lapage. Entre temps, un temporisateur Javascript vérifie toutes les cinquantemillisecondes si cette variable en question est à True pour pouvoir appelerune fonction Flash. Cette technique des deux temporisateurs assure doncune bonne communication entre Flash et Javascript, nécessaire pour cetutilitaire.

Lorsque Javascript est sûr que Flash est bien initialisé, il demande à Flashd’ouvrir une connexion avec le protocole WebSocket sur l’URL fournie parle client. Lorsque Flash reçoit un message, il appelle lui-même la méthodeonmessage(event) sur l’objet WebSocket auquel il est lié. De même, lorsqueJavascript veut envoyer un message sur cette connexion, il appelle une fonc-tion Flash qui effectuera l’envoi effectif. Flash joue donc ici un rôle d’inter-médiaire mais nécessaire lorsque le navigateur n’est pas compatible avec lesWebSockets HTML5. Pour ce qui est de l’expérience utilisateur, il n’y a pasde différence observable, la communication entre Flash et Javascript étanttrès rapide.

Notons enfin que l’utilitaire a été conçu pour permettre la création de plu-sieurs connexions au sein d’une même page Web, si le besoin se fait sentir.En revanche, il n’intègre pas toute l’API, seules les fonctions essentielles sontsupportées, ce qui n’inclut pas la gestion des sous-protocoles, les connexionscryptées et les deux variables readyState et bufferedAmount. Néanmoinsces limitations ne devraient pas poser de problème à la majorité des dévelop-

35

peurs souhaitant établir une connexion bidirectionnelle au sein d’une pageWeb.

Politique de sécurité introduite par Flash

Le protocole HTML5 utilise dans l’établissement de connexion (le hand-shake) des champs permettant d’assurer une politique de sécurité. Le serveurdevant répondre avec une valeur adéquate dans le champ Sec-WebSocket-Origin (cf 3.2.1). Flash de par ses capacités permet de réaliser des connexionsavec des sockets et de laisser le développeur définir son propre protocole.C’est d’ailleurs ce qui a rendu possible la création d’un client Flash pour leprotocole WebSocket. Du fait de cette ouverture, Adobe a défini un autresystème pour gérer la sécurité inter-domaines, afin d’éviter que quelqu’unpuisse reprendre une animation Flash sur son propre site et contacter ainsiun serveur sans l’accord de l’administrateur de ce serveur.

Un article sur le site d’Adobe explique très bien cela [35]. La techniqueutilisée par Adobe consiste donc à ce que le client Flash envoie obligatoi-rement un message contenant <policy-file-request/>\0 au serveur surlequel il souhaite établir une connexion. Le serveur doit lui répondre parun fichier XML définissant la politique de sécurité inter-domaines, donnantainsi l’information au Flash Player si la connexion vers ce serveur depuis lapage Web où le fichier se trouve est permise ou non. Pour une question desécurité supplémentaire, Adobe effectue d’abord une connexion sur le port843 et ce même si le développeur souhaite utiliser un autre port pour sonapplication. La justification de ce port obligatoire double, d’une part Adobeaimerait qu’il soit un standard pour la gestion des accès inter-domaines etd’autre part, sur Unix, utiliser les ports inférieurs à 1024 requiert des droitsd’administrateurs. Néanmoins, si après trois secondes, le serveur appelé surle port 843 n’a toujours pas répondu, le Flash Player renvoie une demandedu fichier XML définissant les droits d’accès mais en n’utilisant cette fois leport défini par le développeur.

Dans une application professionnelle, il est préférable de ne pas avoir cedélai de trois secondes. Deux solutions existent pour cela, soit intégrer lagestion des droits d’accès inter-domaines dans l’application serveur qui gèredéjà les WebSockets, soit de créer une seconde application serveur dédiéeuniquement à cette tâche. L’intérêt étant que le port pour la communica-tion WebSocket peut être différent du port pour la vérification des droitsd’accès (de préférence 843). Dans l’outil développé, le choix a été pris del’intégrer dans l’application serveur pour les WebSockets, de manière à sim-plifier l’utilisation. Il y a ainsi un seul serveur à lancer sur la machine et unseul code à maintenir. Néanmoins, ce choix reste tout à fait discutable tantil y a des avantages pour chaque solution.

36

3.3 Stratégie de communication et format des mes-sages

Après avoir discuté du moyen de communication, il faut définir une stra-tégie de communication afin de réduire au maximum le nombre d’octets quitransiteront sur le réseau et dans le même temps faciliter le traitement desmessages côté client et côté serveur. Cette section commence avec une pré-sentation de cette stratégie puis se terminera avec des explications quant àl’utilisation de JSON et d’un second format minimaliste défini par l’auteurde ce mémoire.

3.3.1 Recherche de l’optimisation de la communication

Optimiser une communication est nécessaire pour augmenter la réac-tivité de l’outil. C’est bien d’avoir éliminé le header HTTP dans chaquemessage (AJAX) et d’être arrivé une bonne connexion bidirectionnelle per-sistante, mais cela a peu d’utilité si les messages qui transitent contiennentde l’information qui n’est pas indispensable ou de l’information qui aurait puêtre réduite dans le nombre d’octets. Cette sous-section recentre la questionde la communication bidirectionnelle si elle est utilisée pour une réunionen ligne ou toute autre application qui implique la présence de plusieurspersonnes s’échangeant de l’information de manière instantanée (discussion,jeu, etc...).

Une véritable stratégie a ainsi été mise en place. Celle-ci consiste en plu-sieurs points :

– Maintenir une petite base de données côté client et côté serveur, quiont pour invariant de contenir à tout moment le même contenu. Cecontenu correspond à des informations sur l’ensemble des clients. Lebut de cette redondance d’information est d’éviter le transfert récur-rent d’informations sur le réseau. Un exemple simple porte sur la dé-finition d’une couleur pour dessiner sur le tableau blanc. Si un par-ticipant change pour la couleur rouge, l’information est envoyée auserveur qui la réplique à tous les autres clients de sorte que les basesde données de ceux-ci se mettent à jour. L’intérêt est que lorsque ceparticipant qui a choisi la couleur rouge dessine, il ne faut plus trans-mettre la couleur mais uniquement les coordonnées du chemin tracé.Le principe est le même pour d’autres paramètres bien sûr. Le but quele serveur possède lui aussi sa base de données, est de permettre decommuniquer celle-ci à un nouvel arrivant. Les opérations à réalisersont :– Un nouveau client envoie ses informations au serveur qui met à joursa base de donnés, puis réplique l’information aux autres clients.

37

– Le serveur envoie la base complète à un nouveau client (comprendau minimum l’identifiant des clients existants)

– Lorsqu’un client change un paramètre, il l’envoie au serveur quimet à jour sa base de donnés, puis réplique l’information aux autresclients.

– Lorsqu’un client reçoit une modification d’un paramètre d’un autreclient, il modifie sa base de données.

– Lorsqu’un client se déconnecte, le serveur le retire de sa base dedonnées puis réplique l’information aux autres clients. (une varianteserait de le déclarer absent afin de sauvegarder ses informations, sic’est jugé nécessaire).

Cette technique demande tout de même d’éviter de mettre trop d’in-formations dans la base de données, afin de ne pas surcharger le clientet le serveur mais aussi car la base de données complète est transmiseà un nouvel arrivant. Le terme base de données est générique, il inclutune gestion avec une liste d’objet ou un tableau, c’est d’ailleurs celaqui a été développé dans l’outil de réunions en ligne. Notons enfin quele serveur se doit de gérer une liste d’ensembles de clients connectés(de réunions) afin de pouvoir par exemple gérer différentes réunionssimultanément sans que les participants à une réunion en aient véri-tablement conscience.

– Laisser le serveur fournir des identifiants aux clients. En effet, à lamanière des adresses IP dynamyque où l’utilisateur se voit attribuerune adresse IP qui ne lui appartient que durant une certaine périodede temps, le serveur garde une liste d’identifiants libres à jour pourl’ensemble des clients connectés au sein d’un même service (ex. uneréunion) et choisit donc des identifiants dans cette liste. L’intérêt estqu’un identifiant est l’information qui transitera le plus sur le réseau.Lorsqu’un client effectue une action, le serveur la réplique avec dansle message l’identifiant en du client qui effectue l’action. Il est doncutile d’éviter des nombres trop grands comme identifiants, de mêmeque d’autres type de caractères afin de réduire au maximum ces iden-tifiants.

– Distinguer deux grands types de messages :1. Ceux contenant beaucoup d’information et / ou apportant un

type d’information rarement mis à jour.2. Autres messages, avec peu d’information et / ou apportant un

type d’information mis à jour régulièrementL’intérêt de cette distinction est dans le format et le traitement de cesmessages par les clients et par le serveur. En effet, le premier type de

38

message a besoin d’un traitement simplifié car susceptible de contenirbeaucoup d’informations et il ne faut pas trop prêter attention à lataille de ce type de messages car ceux-ci sont rarement envoyés. Ilfaut cependant rester raisonnable et c’est ainsi que le format JSONa été utilisé. Pour rappel, l’intérêt de ce format a déjà été abordédans le chapitre portant sur les choix stratégies (cf 2.3.2). Concernantle deuxième type de messages, c’est un format minimaliste qui a étéinventé et qui sera défini plus bas.

En résumé, ce sont donc trois grands principes qui ont été définis, quisont la maintenance de données à la fois côté client et à la fois côté serveur,l’utilisation d’identifiants de service de petite taille définis par le serveur,l’utilisation de deux formats de message à utiliser en fonction du type demessage.

3.3.2 Utilisation du format JSON

JSON dont l’intérêt à été montré plus haut (cf 2.3.2), est utilisé dans lescas suivants :

– <> Renseigner ses informations de base (exemple : nom et numérod’utilisateur) [1 client –> serveur]

– <32> Informer d’une erreur (exemple : le participant a déjà un autreonglet ou une autre fenêtre du navigateur ouverte) [serveur –> 1 client]

– <33> Donner l’identifiant de service au nouveau client [serveur –> 1client]

– <34> Fournir les informations sur un nouvel arrivant [serveur -> n-1clients]

– <35> Fournir les informations des clients existants avant l’arrivée [ser-veur -> 1 client]

– <36> Informer du départ d’un client [serveur -> n clients]

Ces évènements sont valables pour tout service impliquant la mise encontact de plusieurs clients, et ils respectent bien le fait d’apporter beaucoupd’informations (<>, <34>, <35>) et / ou d’être rarement envoyés (cas detous les messages cités, dans des conditions normales). Concernant le numéroattribué à chaque type de message JSON, il sera expliqué dans la prochainesous-section.

3.3.3 Création d’un format minimaliste

Pour les autres type de messages, il y avait le besoin d’un autre formatde données de manière à limiter de manière importante le nombre d’octetscontenus dans ce type de message. Une obligation du protocole WebSocketest que le message doit être encodé au format UTF-8, ce qui exclut donc les

39

messages binaires qui auraient pu servir à ce deuxième type de messages.Voici donc point par point ce qui caractérise ce format défini dans le cadrede ce mémoire.

Les avantages de l’UTF-8

Commençons par rappeler les bénéfices de ce format, à savoir le faitqu’un caractère est représenté sur un nombre d’octets variable, allant de 1octet (caractères dont le code est inférieur à 255) jusqu’à 4 octets. Il permetdonc des caractères très particuliers et dans d’autre alphabets que l’alphabetlatin tout en avantageant les caractères très utilisés qui sont ceux du formatASCII étendu, en les mettant sous 8 bits (un octet). Un autre avantage estqu’il est reconnu comme un standard et est donc facilement manipulable enJavascript, en PHP, et dans bien d’autres langages de programmation.

Encoder un nombre sous forme d’un caractère

Voilà l’idée au coeur de ce format. Etant donné qu’il faut passer pardes caractères UTF-8, la question s’est alors posée d’utiliser le code ducaractère comme encodage d’un nombre. Cela peut surprendre au premierabord car cela revient à détourner l’usage traditionnel du format UTF-8 maisc’est pourtant très efficace car cela revient à encoder des petits nombres enseulement 1 octet. Quant aux nombres plus grands, il faudra là deux octets,voire trois ou quatre pour des grands nombres. Un autre avantage est quel’on peut envoyer deux nombres l’un à la suite de l’autre et aisément lesdistinguer puisqu’ils seront vu comme des caractères différents. Cela éliminedonc aussi l’usage de séparateurs entre différentes valeurs.

Cette idée mérite cependant d’être adaptée du fait de l’utilisation dé-tournée de l’UTF-8. Ainsi, il est fortement déconseillé voire problématiqued’utiliser les caractères ayant un code compris entre 0 et 31. Il en va demême pour le caractère 92 (backslash) et le caractère 255 (marqueur de find’un WebSocket). Enfin, il est évident que les nombres négatifs sont exclusen utilisant cette technique. Pour résoudre ce problème, un décalage est ef-fectué avant l’envoi sur le réseau et il est refait dans l’autre sens lors de laréception d’un message. Ainsi, tout nombre positif de grandeur raisonnable(inférieur au million) peut être encodé en un minimum d’octets.

Utilisation du premier caractère

C’est donc en suivant cette logique d’encodage de nombres dans descaractères que le premier caractère a un rôle déterminant dans ce format.En effet, il indique le type exact du message (au sens applicatif) et introduitla notion dumessage le plus important. Voici les codes de caractères possiblespour ce premier caractère avec leur signification :

40

– <32> Message au format JSON– <33> ... <49> Message qui sera répliqué à tous les autres clientsconnectés au service (n’inclut pas l’expéditeur)

– <50> ... <54> Message qui ne sera pas répliqué (envoi d’informationau serveur)

– <55> ... <61> Message qui sera répliqué à tous les clients connectésau service (inclut l’expéditeur)

– <62> ... <MAX> Message dit message le plus important, répliqué àtous les clients connectés au service (inclut l’expéditeur)

Quelques explications s’imposent :– Les valeurs comprises entre 33 et 61 doivent avoir une significationdans l’application réalisée. Par exemple, le 33 signifie que c’est unmessage informant qu’utilisateur commence à dessiner dans l’outil deréunions à distance. La signification exacte de chaque numéro pourl’outil de réunions sera expliquée plus bas.

– La valeur 32 indique donc que le message est au format JSON. C’estainsi une manière simple et claire visant à créer un format hybride. Lecaractère qui suit (le second caractère dans le message) a pour code letype du message JSON, tel que défini plus haut (voir 3.3.2), sauf dansle sens client –> serveur où il n’y a qu’un message JSON et donc pasbesoin de type. C’est donc à partir du troisième caractère que com-mence le véritable message encodé avec JSON (deuxième dans le sensclient –> serveur).

– L’intérêt de messages sans réplication est par exemple pour la fonc-tionnalité liée au placement des vidéos en fonction des personnes quiparlent, où les clients envoient une information au serveur et le serveurpeut à un certain moment envoyer un message demandant un change-ment de places. Ce n’est donc pas de la pure et simple réplication demessage.

– L’intérêt des messages renvoyés à l’expéditeur est d’avoir une idée dutemps de réponse du serveur et donc ce que les autres voient. Il y ad’autres buts comme par exemple le chat texte qui utilise ce type demessages afin d’assurer que l’ordre des messages affichés sera le mêmepour tous.

– La notion dite du message le plus important est en fait un type spé-cifique de message au niveau applicatif, qui risque fort d’avoir uneimportance très élevée et donc d’être utilisé de manière importante.Dans l’outil de réunions, il s’agit de la fonctionnalité dite du Displayer

41

qui permet de montrer en temps réel la position courante du curseurde la souris aux autres participants (cf 2.4.1). L’intérêt de cette no-tion est que le premier caractère n’est plus le type du message maisl’identifiant service du client auquel est lié le message. Ce n’est doncqu’un octet de gagné mais du fait de son utilisation massive et de laréplication à tous, c’est au final de nombreux octets épargnés. Notonsque la fonctionnalité Displayer contient exclusivement des messagescomposés de 3 octets seulement, en plus des deux octets servant demarqueurs tel que définis par le protocole HTML5.

Ces trois octets sont dans l’ordre, l’identifiant service du client, lacoordonnée X compressée et la coordonnée Y compressée. Le mot com-pression s’entend avec pertes, il s’agit en d’une division entière par 3 dela valeur de la coordonnée, où le 0 signifie le coin supérieur gauche dela zone du tableau blanc et non de l’écran ou de la page Web complète.Ainsi, sachant que X peut aller jusqu’à 600 (largeur du tableau blanc),qu’il y a une division entière par 3, ce qui le réduit à 200 mais qu’il ya 33 codes de caractère inutilisables, cela laisse une valeur maximumde 233, ce qui est bien inférieur à 255 et pourra donc être encodée parUTF-8 en un seul octet. Concernant la perte de précision due à cettedivision entière par 3 puis multiplication par 3, elle est acceptée étantdonné que le but est de montrer un point à l’écran et cela n’oblige pasà travailler au pixel près, ce qui serait inutilement précis. Il convientaussi de dire que le client n’enverra pas de messages tant que le curseurn’aura pas été déplacé de minimum 3 pixels, puisque la compressionrendrait ces envois inutiles. En résumé, la fonctionnalité Displayer uti-lise des messages de 3 octets et n’est utilisée que pour un déplacementde plus de 3 pixels, ce qui permet d’augmenter de manière importantela réactivité de cette fonctionnalité.

Valeurs des identifiants service

Comme le laissait penser l’explication donnée ci-dessus, les identifiantsservice ont une valeur minimale de 62. C’est en effet en décalant de 30unités supplémentaires que cela rend possible la notion de message le plusimportant et la définition de 29 types de messages au niveau applicatif, enplus de messages au format JSON.

Outil de réunions : Types de niveau applicatif

C’est le moment à présent de présenter les différents types de messagespour l’outil de réunions. Pour comprendre cette liste, c correspond à identi-fiant service d’un client, s à numéro d’un slide, p à numéro d’une page, k à6 caractères définissant un code couleur en hexadécimal, l à l’épaisseur du

42

crayon, t à un texte (chaîne de caractères classique en UTF-8), n au numérod’une place privilégiée, a à l’activité du microphone, x à la coordonnée enX (sans compression) et y à la coordonnée en X (sans compression).

– <33> csxy = L’utilisateur c commence à dessiner sur le slide s et estau point (x,y) sur le tableau blanc

– <34> csxy = L’utilisateur c dessine sur le slide s et est au point (x,y)sur le tableau blanc

– <35> csxy = L’utilisateur c termine de dessiner sur le slide s et estau point (x,y) sur le tableau blanc

– <36> csxy = L’utilisateur c gomme sur le slide s et est au point (x,y)sur le tableau blanc

– <37> ck = L’utilisateur c change sa couleur de dessin pour la couleurk

– <38> cl = L’utilisateur c change l’épaisseur du crayon pour la valeur l

– <40> cs = L’utilisateur c change le slide affiché pour le slide s– <41> cp = L’utilisateur c change la page affichée pour la page p

– <43> cpxy = L’utilisateur c commence à dessiner sur la page p et estau point (x,y) sur le tableau blanc

– <44> cpxy = L’utilisateur c dessine sur la page p et est au point (x,y)sur le tableau blanc

– <45> cpxy = L’utilisateur c termine de dessiner sur la page p et estau point (x,y) sur le tableau blanc

– <46> csxy = L’utilisateur c gomme sur la page p et est au point (x,y)sur le tableau blanc

– <55> ca = L’utilisateur c a une activité moyenne de a au microphone

– <55> ct = L’utilisateur c a écrit le texte t– <56> c = L’utilisateur c signale qu’il commence à envoyer l’image desa webcam et le son de son microphone

– <57> cn = Le serveur demande de mettre l’utilisateur c à la placeprivilégiée n

Les explications quant à l’utilité des informations dans les messages etle choix de leur contenu seront données les deux prochains chapitres de cemémoire.

43

3.4 Développement du moduleCe chapitre portant sur la gestion de la communication entre les dif-

férents clients a présenté une solution pour effectuer des connexions bidi-rectionnelles au sein d’une page Web ainsi qu’un format de messages per-mettant de créer des applications Web interactives où plusieurs personnessont connectés, et ce avec une recherche de l’optimisation dans la réactivité.Lorsque tout cela est bien défini, il reste à procéder au développement dumodule en question. Pour rappel, celui-ci utilise les WebSockets HTML5 ennatif si disponible ou via Flash grâce à l’utilitaire réalisé dans le cadre dece mémoire. Au niveau du code, ce sont donc l’API WebSocket HTML5 quipeut être utilisée sans crainte de réduire l’accessibilité. Cette section va donccommencer par présenter la partie client puis il sera question du serveur.

3.4.1 Développement de la partie client

Ce module développé en Javascript se trouve dans le fichier WebSocket-Client.js généré entre autres à partir de WebSocketClient.hx. Il contientdifférentes fonctions d’envois de messages (avec ajout ou non de l’identifiantservice de l’utilisateur, du type de message) et deux fonctions pour l’en-codage et le décodage de nombres, comme expliqué dans la définition duformat de message.

Authentification d’un utilisateur

Lorsque la fonction onconnect(event) est appelée, que ce soit par le na-vigateur ou par l’animation Flash, cela indique que la connexion a été établieavec le serveur. Pour que l’utilisateur soit reconnu dans le système, le clientenvoie à ce moment un message avec les informations de l’utilisateur (sonnuméro d’utilisateur, son nom et le numéro de la réunion à laquelle il veutparticiper, ...). Ce message est capital car c’est une sorte d’authentificationau serveur. Il serait d’ailleurs possible d’ajouter une sécurité via ce principelà, en donnant les moyens au serveur de vérifier si l’utilisateur a bien le droitd’accéder à la réunion. L’outil développé ne gère pas cela mais l’ajouter neserait pas bien compliqué. Dès lors, la seule vérification effectuée côté serveurest d’empêcher qu’un même utilisateur (via son numéro sensé être unique)ouvre deux connexions pour la même réunion.

Le serveur reçoit donc cette demande d’authentification, et il y a alorsdeux cas possibles. Le cas classique est qu’il accepte l’utilisateur et lui com-munique son identifiant service. Par la même occasion, il lui communiqueaussi les informations qu’il connaît sur les clients déjà présents avant l’ar-rivée de l’utilisateur. Le serveur se charge également d’envoyer à ces clientsdéjà présents les informations à propos du nouvel utilisateur, afin que tout

44

le monde ait bien une base de données à jour. L’autre cas de figure possibleest un refus de l’utilisateur par le serveur, ce dernier lui envoie alors unmessage d’erreur qui contient un code d’erreur. Le client recevant ce coded’erreur peut y faire correspondre un message dans la langue de l’utilisateurà donner à celui-ci.

Cette étape d’authentification couplée à la mise à jour des bases de don-nées de tous les clients connectés au service peut paraître complexe, maisen réalité cela ne prend que très peu de temps et améliorera le confort pourla réunion en elle-même du fait des données répliquées chez chaque client.Concernant la réception de messages par le client, c’est un bloc switch surle premier caractère qui détecte que le message est en JSON, puis alors unswitch sur le deuxième caractère pour déterminer le type de contenu dumessage.

Dans l’application, le choix été pris de créer une classe (un prototype)MeetingUser qui regroupe les informations d’un utilisateur et contient uneméthode pour modifier ses informations et une autre pour déclarer le dé-part de l’utilisateur, ce qui revient à faire des changements dans l’interfacede manière à ce que ce soit visible à l’écran. La classe WebSocketClientcontient donc une structure de données regroupant plusieurs objets de Mee-tingUser avec accès en O(1) aux informations d’un utilisateur sur base deson identifiant service.

Gestion des messages une fois l’utilisateur authentifié

Après authentification, le client va donc être amené à émettre et re-cevoir des messages. L’envoi de messages se déroule comme expliqué plushaut, c’est-à-dire avec différentes fonctions facilitant leur envoi en respec-tant le format de messages. Pour ce qui est de la réception de messages, c’estle bloc switch sur le premier caractère qui identifie le type du message etappelle des fonctions effectuant les modifications visibles pour l’utilisateur.Le bloc switch contient également le cas par défaut qui représente la notionde message le plus important.

Les deux prochains chapitres décriront exactement quand et pourquoicertains messages sont envoyés et les effets précis de leur réception sur l’in-terface utilisateur, cette section-ci ayant pour but de présenter le moduleclient gérant la communication avec le serveur.

3.4.2 Développement de la partie serveur

La partie serveur utilise le serveur PHPWebSocket [2] adapté par un Mi-chael Feichtinger [12] qui propose quelques améliorations dans l’utilisation,

45

avec entre autres l’utilisation d’une fonction callback pour le traitement desmessages. Quelques adaptions personnelles ont été réalisées comme la ges-tion des identifiants serveur et des groupes d’utilisateurs afin de permettreplusieurs réunions simultanées avec des utilisateurs différents.

Le choix de ce serveur en PHP a été pris pour sa simplicité d’utilisation etune architecture intéressante utilisant les classes PHP5. Il serait néanmoinsintéressant de créer une version en Neko VM qui utiliserait plusieurs filsd’exécution (multi-threads). Il faudrait par contre alors prêter attention auxdifférents problèmes qui peuvent survenir liés à l’utilisation de tâches concur-rentes. L’intégration à Apache HTTP Server comme le propose Google [38]serait aussi intéressant à évaluer. Cependant, cette étude comparative surles serveurs WebSocket sort du cadre de ce mémoire et n’a donc pas étéréalisée.

Pour la réception de messages, le serveur utilise lui aussi un bloc switch surle premier caractère, à l’instar de la partie client. Le serveur a en outre à gérerles déconnexions de clients, où il a pour mission de prévenir les utilisateursencore présents du départ de l’utilisateur dont le serveur a été informé desa déconnexion. C’est important que ce soit le serveur qui s’occupe seul decette tâche, étant donné que le client peut être déconnecté par exemple suiteà une perte de connexion Internet.

Enfin, en plus des rôles de réplication de messages et d’authentificationdes utilisateurs, le serveur a aussi un rôle d’arbitre sur le placement des vi-déos. Ce rôle sera expliqué dans le chapitre sur la vidéoconférence. Un autrerôle intéressant qui pourrait être rajouté au serveur serait de sauvegarderl’entièreté des messages de manière à ce qu’un utilisateur puisse revivre laréunion comme s’il y était ou du moins obtenir un résumé d’une réunion.Cela n’a pas été développé dans l’outil réalisé car cela demande une ges-tion adéquate à définir, concevoir et implémenter afin d’obtenir une solutionpropre et extensible. Attachant plus d’importance à la qualité de l’outil etde son architecture plutôt qu’à la quantité de ses fonctionnalités, ce rôle desauvegarde avec tout ce qu’il implique n’a pas été développé.

46

Chapitre 4

Développement du tableaublanc collaboratif

Après avoir longuement discuté de la technologie et de la stratégie adop-tée pour la gestion de la communication entre les différents utilisateurs, ilconvient de parler des outils utilisant ce système, de comment ceux-ci ontété pensés afin d’apporter la meilleure expérience utilisateur possible, en larendant accessible à tous.

L’outil au coeur de l’application développée est un tableau blanc colla-boratif doté de quelques fonctionnalités innovantes en soi et pensé pourl’extensibilité de ses utilisations. A ce tableau blanc s’ajoute un petit espacede discussions en mode texte (chat texte) et l’outil Displayer déjà évoqué audébut de ce mémoire. Ce chapitre va donc s’intéresser au module composédu tableau blanc collaboratif et de ses fonctionnalités liées. Il commencerapar une explication sur ses objectifs et les moyens de les atteindre puis dé-taillera comme le patron de conception MVC a pu être employé pour faciliterl’implémentation et assurer la maintenance de l’application. Enfin, commepour le chapitre précédent, il se terminera avec une présentation du déve-loppement de ce module et de ses fonctionnalités.

4.1 Objectifs visés et moyens de les atteindreComme pour toute application, les objectifs majeurs sont l’expérience

utilisateur et l’accessibilité de l’application qui doit s’approcher des 100%des utilisateurs. Il faut aussi veiller à ce que l’application soit aisément main-tenable et extensible afin de pouvoir continuer à offrir une expérience uti-lisateur confortable. Pour cela, cela passe comme toujours par le choix detechnologies en prêtant attention à ce qu’elles permettent de réaliser et àleur compatibilité sur les machines des utilisateurs.

47

Etant donné l’environnement de chaque utilisateur, les spécificités et l’ac-cessibilité des technologies existantes, le choix a été pris de ne pas se res-treindre à une seule technologie. En effet, contrairement à la communicationentre les différents intervenants qui peut se passer complètement en Javas-cript, moyennant toutefois l’usage d’un adaptateur pour certains naviga-teurs, un tableau blanc qui serait totalement réalisé en Javascript aurait unimpact négatif sur une partie des utilisateurs. Cette section va donc discuterdes différentes technologies puis expliquera un moyen qui a été pensé afin depouvoir en utiliser plusieurs tout en répondant aux objectifs de maintenanceet d’extensibilité.

4.1.1 Technologies choisies

En mars 2010, Cameron Adams a réalisé un test de performance dedifférentes technologies pour réaliser des animations dans des pages Web(voir [3]). Un tableau blanc peut être vu comme une sorte d’animation crééepar un utilisateur et qui s’affiche chez d’autres utilisateurs, idéalement à lamême vitesse que la personne qui l’utilisé. Les performances liées à l’échanged’information entre les utilisateurs ont été présentées dans le précédent cha-pitre, il reste donc à optimiser le rendu-même du tableau blanc. Pour celadifférentes, technologies existent comme HTML5 Canvas, HTML div/span,SVG, Flash, et d’autres via d’autres plugins (Java, Silverlight, ...). Les figures4.1 et 4.2 représentent le résultat du test de performance sur respectivementMac OS X avec Firefox 3.6 et Windows XP avec Internet Explorer 8. Le testconsiste à animer un ensemble de particules à la vitesse maximum possible.

Résultats du test

Comme indiqué au bas de la seconde figure, la version actuelle d’InternetExplorer (8.0) peut utiliser HTML5 Canvas et ce avec une librairie Javas-cript, Excanvas pour Explorer Canvas ([26]) qui se charge de l’émuler. Lesrésultats de cette émulation sont hélas très décevants en terme de perfor-mance.

A ces deux figures, il convient d’ajouter le résultat sur Linux, Ubuntu8.10 64bit, Google Chrome 5 qu’une personne a posté en commentaire del’article. Le résultat en nombre d’images par seconde pour 500 particules estde 50 pour Flash 10, 85 pour Canvas, 50 pour HTML et 55 pour SVG.

Un autre point important concerne l’utilisation de l’accélération maté-rielle. Depuis octobre 2008, date de sortie de Flash Player 10, les capacitésde la carte graphiques (GPU) sont utilisées. Pour ce qui est des technolo-gies du Web, HTML5 Canvas par exemple, un des premiers navigateurs àles utiliser devrait être Internet Explorer 9 pour la fin 2010 ou début 2011.

48

Figure 4.1 – Comparaison de technologies [Mac OS X, Firefox 3.6] (figurereprise de [3])

Figure 4.2 – Comparaison de technologies [Windows XP, Internet Explorer8] (figure reprise de [3])

49

Une version Preview existe déjà et une personne a commenté les résultatsobtenus avec 500 particules qui sont de 30 FPS pour SVG et 25 FPS pourHTML. D’autres améliorations ont été réalisées depuis sur la nouvelle ver-sion d’Internet Explorer, qui pourraient peut-être améliorer ces résultats.

Il est important aussi de rappeler que cet usage, l’animation d’imagesvectorielles, est précisément le but initial de Flash Player, qui s’appelaitinitialement FutureWave et qui fût créé en 1993. Il y a donc un travailconséquent qui a été apporté sur ce logiciel, par Macromedia depuis 1996,puis par Adobe Systems depuis 2005. L’HTML n’avait pas été pensé pourcela à la base, SVG et l’HTML5 Canvas pourront être améliorés grâce auxmoteurs Javascript qui s’améliorent énormément, notamment du fait de laconcurrence qui existe entre les différents navigateurs. Ceux-ci incluent ouvont inclure pour la plupart la compilation à la volée (JIT pour just-in-timecompilation) qui revient à convertir Javascript en du code machine natifavant de l’exécuter.

Notons enfin que ces tests sont réalisés sur des ordinateurs de bureau.Pour ce qui est des appareils mobiles tel que des smartphones, une vidéo dece test a été publiée ([27]) et les résultats s’avèrent relativement semblablesà ceux montrés pour les ordinateurs de bureau.

Analyse des résultats

Même si une nouvelle fois, il ne s’agit là qu’un test particulier, il estintéressant d’observer que Flash obtient des performances très intéressantespour Windows, alors que pour Linux, c’est l’HTML5 Canvas qui l’emporte.Mais il faut relativiser ces chiffres et juger ceux à un niveau acceptabled’images par secondes pour l’oeil humain, lequel avoisine les 25 FPS (FramesPer Second).

Ensuite, il faut considérer le but du module à développer, un tableaublanc, lequel demande moins de ressources que 500 particules en mouvement.Mais alors, il faut aussi admettre que la solution HTML pur, au sens demodifier la position d’éléments dans la page Web, n’est pas vraiment adaptéepour un tableau blanc. En effet, il faudrait en fait créer une planche d’objetsde 1 pixel et colorer ceux-ci lorsque l’utilisateur passe dessus avec la sourisenfoncée. Le désavantage de cette technique est qu’il n’y a aucune APIdisponible à cet effet, il faudrait tout refaire. Cette option peut donc êtreéliminée, bien que toutefois techniquement utilisable.

50

Technologies utilisées pour le tableau blanc

Deux technologies ont été retenues, Flash et HTML5 Canvas. La tech-nologie SVG reste une option intéressante mais le développer en plus desdeux autres n’a pas été jugé nécessaire, du fait que Flash et Canvas per-mettent déjà d’offrir une accessibilité importante et des performances trèsintéressantes. Cependant, afin de fournir la meilleure expérience utilisateurpossible, il a été choisi de donner la possibilité de changer de technologie enun clic et ce directement dans la page Web, sans devoir recharger la pageet donc sans devenir absent de la réunion durant le passage d’une techno-logie à une autre. En effet, l’application choisira une technologie à afficherselon le navigateur de l’utilisateur, Flash pour Internet Explorer 6, 7 et 8,HTML5 Canvas pour les autres. C’est après que si l’utilisateur le désire, ilpeut changer la technologie en un clic. Notons que Flash apporte une parti-cularité intéressante, le plein écran sur la machine du client et possède desAPI de lissage du contenu, qui peuvent améliorer l’expérience utilisateur. Ilest donc possible via une ligne de Javascript d’imposer à l’application unetechnologie à afficher par défaut.

L’idée d’offrir deux moyens technologiques pour utiliser l’application peutsurprendre et laisser penser que cela pourrait doubler la quantité de tra-vail inutilement. Certaines personnes diront que Flash aurait suffit, étantprésent sur près de 98% des machines connectées à Internet et apportantl’expérience utilisateur requise. D’autres diront que l’HTML5 Canvas vacontinuer à s’améliorer et que le support d’Internet Explorer avec Excanvasest suffisant. Personnellement, ces discours ne me conviennent pas car lepremier apparaît comme une solution de facilité qui ne tient pas compte deslogiciels libres dont Linux et le second réduit considérablement l’expérienceutilisateur sur près de 60% des utilisateurs d’Internet. Une solution hybrideme semble donc justifiable et intéressante à développer, à l’instar de You-tube qui propose son lecteur vidéo aussi bien avec Flash qu’avec la balisevidéo du langage HTML5.

4.1.2 Moyens de les utiliser conjointement

L’utilisation de plusieurs versions d’un même programme est considérée,à juste titre, comme un point négatif pour la maintenance du programme.Même si le choix s’est arrêté sur deux versions, cela augmente la charge detravail lors de la maintenance. C’est hélas un fait et une conséquence decette décision. Cependant, il est possible de réfléchir à des solutions pourréduire l’impact négatif d’un modèle à plusieurs versions.

La réflexion a donc été menée pour offrir deux versions tout en réduisantles effets négatifs sur la maintenance et l’extensibilité. C’est là qu’une idée

51

m’est venue, assez originale, surprenante au premier abord et qui peut laissercraindre un effet négatif sur l’expérience utilisateur cette fois. Cette idée estd’utiliser Javascript pour contrôler aussi bien HTML5 Canvas que Flash. Al’inverse de Youtube qui possède deux versions du lecteur vidéo avec tousles boutons de contrôle et la gestion de ceux-ci doublée, l’idée est ici den’utiliser qu’un seul moyen de contrôle, Javascript. Flash et HTML5 Canvasapparaissent ainsi juste comme des objets ne servant qu’au rendu graphiqueet répondant aux demandes effectuées par Javascript.

Ce qui est décrit dans le paragraphe précédent est en fait le patron deconception MVC (Modèle - Vue - Contrôleur), étudié dans différents cours àl’Université Catholique de Louvain et revu notamment dans le séminaire degénie logiciel. Son architecture a pour avantage de faciliter la maintenance etl’extensibilité, les points négatifs du modèle à plusieurs versions. Il permetaussi la gestion de plusieurs vues et a donc pu être utilisé dans ce mémoirecomme un bon moyen d’utiliser plusieurs technologies conjointement. Deplus, rappelons que l’usage de HaXe comme langage commun pour Flash etJavascript vient faciliter davantage l’implémentation des deux vues, que sontFlash et HTML5 Canvas. Enfin, l’architecture de l’application et ce patronde conception, MVC, permet d’ajouter d’autres vues très simplement, dumoment que celles-ci aient une connexion avec Javascript.

4.2 Emploi du patron de conception MVCL’usage du patron de conception (design pattern) MVC, Modèles - Vue

- Contrôleur, a été réalisé dans un but de gestion multi-vues simplifié, etnon dans le but de complexifier le programme avec de multiples appels defonctions qui viendraient réduire l’efficacité, la maintenance et la clarté desopérations effectuée par le programme. Le reproche est ici fait aux instan-ciations d’un patron de conception qui s’intéressent plus à respecter desrègles qu’à développer une architecture claire et efficace d’un programme.Cela entraîne une multitude de dossiers, de fichiers, et ceux-ci contenant unemultitude de classes, de fonctions, d’appels de fonctions et tout cela pourparfois une application très simple qui aurait pu être faîte d’une manièrebien plus claire et élégante. Néanmoins, l’avantage réside entre autres dansla construction de framework directement utilisables dans une application.

Dans le cadre de ce mémoire, il a été choisi de construire une architecturepropre et simple à ce module de tableau blanc. La figure 4.3 représente ainsila manière dont s’articule cette partie de l’outil de réunions en ligne, enmontrant en plus l’utilisation de HaXe pour générer Javascript et Flash. Lessous-sections qui suivent auront pour but de décrire chaque composant dece patron de conception instancié pour cette application.

52

Figure 4.3 – Schéma du modèle MVC instancié pour le tableau blanc

4.2.1 Modèle

Le modèle est donc ici la classe WebSocketClient avec ses objets de laclasse MeetingUser. Ce composant sauvegarde et maintient à jour les diffé-rentes données de l’application incluant celles liées au tableau blanc (couleurde dessin, épaisseur du crayon) et ce pour chaque participant d’une réunion(ou plus largement d’un service interactif).

C’est aussi ce composant qui reçoit les commandes à exécuter sur le ta-bleau blanc et se charge donc de les communiquer au composant contrôleurafin qu’il demande à la vue affichée de se mettre à jour. Cela explique laflèche en pointillés sur le schéma qui va du modèle vers le contrôleur.

La flèche qui va du contrôleur vers le modèle représente en fait les actionsréalisées par l’utilisateur et que le contrôleur reçoit sous la forme d’évène-ments ou d’appels de fonctions. Un changement de couleur de l’utilisateurcourant est donc perçu par le contrôleur via un appel de fonctions et il estcommuniqué aux modèle afin que les données sur la machine du client soientà jour mais aussi afin d’envoyer l’information au serveur pour que tout lemonde dispose bien des mêmes données. Pour ce qui est des évènements, ily a les contrôles au clavier et à la souris que le contrôleur perçoit et qui luipermet de lier ces évènements à des appels de fonction, selon par exemplel’outil sélectionné (gomme ou crayon).

Enfin, les données stockées par le modèle sont sous forme d’objets et non debases de données SQL. Il n’y a en fait pas un besoin réel pour construire une

53

base de données SQL étant entendu le peu d’informations à sauvegarder. Deplus, l’utilisation d’objets apporte des avantages intéressants liés au principede la programmation orienté objet (méthodes entre autres).

4.2.2 Vues

La figure 4.3 représente les deux vues qui ont été développées, l’une avecFlash, l’autre avec HTML5 Canvas et le tout à partir de HaXe. L’architec-ture du module a été pensée pour accueillir d’autres vues si nécessaire. Cequi est important de voir sur ce schéma est le lien unidirectionnel entre lecontrôleur et les vues. En effet, cette instanciation du patron de conceptionMVC repose sur des vues passives, qui ne font qu’exécuter les commandesqu’elle reçoivent du contrôleur. Les évènements sont d’ailleurs perçus parle contrôleur. L’intérêt de telles vues est d’avoir un couplage faible avecle contrôleur pour faciliter maintenance et extensibilité, deux notions quireviennent souvent dans ce mémoire et qui se veulent essentielles pour unprojet sérieux.

L’impact de vues passives est que le code de ces vues est dès lors trèsréduit et très simple à modifier quand on en a le besoin. C’est importantde souligner que dans une application avec plusieurs versions à maintenir,pouvoir réduire la partie spécifique à chaque version est bénéfique car celaréduit la charge de travail pour la personne qui souhaiterait ajouter de nou-velles fonctionnalités à ce tableau blanc. Pour rappel, il ne contient que deuxoutils, un crayon et une gomme, mais de par son architecture, en ajouterdevrait être relativement simple (dessin de forme, texte, fluo, ...) tant le codeprincipal se situe au niveau du contrôleur qui est commun à toutes les vues.

Enfin, il convient d’introduire le plein écran de ce tableau blanc, unique-ment pour la vue Flash, l’HTML5 ne disposant pas d’API pour ce but.Notons qu’il est ici question de plein écran complet et non de remplissagetotal de la fenêtre du navigateur. Donc, pour Flash, le plein écran a pourconséquence que Flash est placé au premier plan et donc c’est lui qui a lacapacité d’intercepter les évènements de souris et de clavier. C’était doncun problème potentiel qui aurait pu compromette l’architecture présentéedans la figure 4.3 et augmenter le couplage. Mais ce n’est pas le cas, unesolution simple et claire a été trouvée. Celle-ci consiste à ce que Flash, lors-qu’il est en plein écran, transfert les évènements qu’il reçoit au contrôleur.Il s’agit bien de transfert sans aucune intelligence, c’est toujours le contrô-leur qui reste l’unique maître pour décider des actions à effectuer. La bonneconnexion entre Flash et Javascript ne crée pas de latence visible et préservel’expérience utilisateur voulue pour ce module.

54

Figure 4.4 – Scénario adapté lorsque la vue Flash est en plein écran

Figure 4.5 – Scénario classique

La figure 4.4 présente un scénario qui arrivera très souvent durant uneréunion en ligne. Ce scénario consiste à l’appui sur la touche clavier 39,qui correspond à la flèche droite sur un clavier dans la partie composée desquatre flèches directionnelles. Cet évènement a pour effet de passer d’un slideà un autre si l’utilisateur est actuellement sur un slide ou d’une page blancheà une autre si l’utilisateur est actuellement sur une page blanche. Commela figure le montre, Flash en plein écran devient récepteur des évènementsmais il ne fait que les transférer au contrôleur. Ce dernier choisit de passer auslide suivant ou à la page blanche suivante selon le mode actuellement utilisé.Dans ce scénario, le mode utilisé serait les slides. C’est donc le passage auslide suivant qui devra être opéré. Le contrôleur va donc demander à la vueFlash de passer au slide suivant puis demandera au modèle de communiquercette information aux personnes connectées au service, afin que le passageau slide suivant se produise chez tous les utilisateurs. Notons que ce schémaest simplifié car dans la réalité le contrôleur ne demande pas de passer auslide suivant mais précise le numéro du slide, et ce afin d’avoir un moyengénérique de passer d’un slide à un autre mais aussi que ce n’est pas le

55

rôle d’une vue de mémoriser le numéro actuel du slide. Ce raisonnement estidentique pour les pages blanches bien sûr.

Comme il est possible de l’observer sur la figure 4.5, lorsque la vue n’est pasen plein écran, et qu’elle soit en Flash, HTML5 Canvas ou autre, le scénarioest bien plus simple, il n’y a plus de transfert d’évènements. Cependant,soulignons que le transfert d’évènements est quelque chose de générique etsimplifié qui n’aura donc aucun impact sur la maintenance de l’application.

4.2.3 Contrôleur

Le troisième élément dont beaucoup d’informations ont déjà été donnéesplus haut est le contrôleur. C’est véritablement lui qui est le relais entre unevue dans une technologie particulière et les données reçues par la connexionWebSocket. C’est également lui qui intercepte les évènements et décide del’action à mener ensuite.

Ce composant dispose aussi d’une gestion des différentes vues et c’est grâceà lui que l’utilisateur pourra passer d’une vue HTML5 Canvas à Flash ouinversement, sans nécessiter de rechargement de la page Web. Il est ici impor-tant de noter que comme cela avait été pensé pour l’utilitaire de compatibi-lité des WebSockets, le contrôleur ne demandera le chargement que des vuesnécessaires dans la page Web. Ainsi, si la vue par défaut est Flash, le fichierCanvasWhiteBoard.js n’aura pas été chargé par le navigateur. De même, sila vue par défaut est HTML5 Canvas, le fichier FlashWhiteBoard.swf n’aurapas besoin d’être chargé non plus.

Enfin, le contrôleur dispose d’un moyen générique pour l’initialisation devues. C’est en effet un problème important dû notamment à l’utilisationd’une connexion asynchrone pour insérer les composants d’une vue commeun objet Flash ou une balise Canvas avec un fichier Javascript. De plus,une fois le téléchargement effectué, il faut pour Canvas que les prototypesen Javascript soient bien déclarés et pour Flash que la machine virtuelleait bien exécuté le fichier SWF. C’est pourquoi le contrôleur a la charge deveiller à la bonne initialisations des vues, puis à envoyer des commandespour les différents paramètres à utiliser tel que la couleur ou l’épaisseurdu crayon par exemple. En effet, dans un but d’efficacité, les vues ont unepetite mémoire stockant ces paramètres et le contrôleur ne demande à lavue affichée de changer ces paramètres que lorsque cela s’avère nécessaire.C’est donc bien le contrôleur qui garde le contrôle de ces paramètres et c’estle modèle qui stocke ces paramètres pour chaque personne connectée auservice. La mémoire incluse dans la vue ne contient donc que les paramètrescourants à utiliser et non les données pour chaque utilisateur.

56

4.3 Développement du moduleLe développement de ce module n’est à réaliser que pour la partie client

étant donné que la partie serveur consistant à la gestion des messages liés àce tableau blanc a déjà été discutée dans le chapitre précédent. Il s’agit icid’expliquer l’implémentation effective de ce module pour la partie client.

4.3.1 Implémentation du modèle

L’implémentation du modèle se retrouve dans les fichiers WebSocket-Client.hx et MeetingUser.hx. En lien étroit avec le contrôleur, il dispose defonctions que le contrôleur peut appeler pour faire envoyer une commandeaux autres clients connectés au service. Cela vise à ce que la gestion dela communication reste bien dans les mains du modèle et non dans cellesdu contrôleur. Ainsi, si le besoin se fait sentir de modifier le protocole decommunication, le contrôleur et les vues n’en seront pas impactées.

De même, pour ce qui est de commandes reçues par le modèle, celui-ci vaappeler des méthodes que le contrôleur lui a données à cet effet. C’est doncune API d’échange entre le module et le contrôleur qui a été pensée afin dediminuer le couplage.

4.3.2 Implémentation du contrôleur

Le contrôleur a son code source dans le fichier WhiteBoard.hx et estpour rappel exclusivement en Javascript. Il s’occupe entre autres de lagestion des vues avec des fonctions pour insérer une vue et une gestionpour l’initialisation d’une vue. Celle-ci s’opère au moyen d’une variableis\_viewInitialized} qu’une vue se charge de mettre à True en appelantla fonction setViewInitialized(). Il s’agit là du seul lien qui va d’une vuevers le contrôleur, c’est pourquoi il ne figurait pas sur la figure 4.3.

Gestion des vues

L’idée a été d’avoir une variable whiteBoard qui est en fait une référencede la vue. C’est assez intéressant d’expliquer que cette variable contiendrasoit une référence à un objet Javascript, soit une référence à un objet SWF se-lon la vue affichée. Ainsi, Flash et Javascript ont pour mission d’implémenterles mêmes fonctions avec le respect parfait de la signature de ces fonctions.Ainsi cela décharge bien les responsabilités et ça simplifie le contrôleur quipeut utiliser la variable whiteBoard comme unique point d’accès à la vue.Cela revient dès lors à abstraire une vue et à ce que ce soit la vue elle-mêmequi utilise les spécificités liées à sa technologies comme par exemple le lissage(smoothing).

57

L’ajout d’une nouvelle vue demanderait au minimum– de créer une fonction d’insertion des composants de cette vue. Cettefonction devra en outre définir la variable whiteBoardString qui estune représentation sous forme de chaîne de caractères de la variableà utiliser pour communiquer avec la vue, et devra également appelerinitializeView() qui est une fonction générique d’initialisation devue.

– d’attribuer un numéro à la vue et d’ajouter dans le switch de la fonc-tion changeView(view : Int) un appel à cette fonction d’insertiondes composants pour ce numéro.

– que la vue appelle la fonction setViewInitialized()– qu’elle implémente les différentes fonctions que le contrôleur peut ap-peler (API)

Bien que ce procédé d’ajout d’une vue reste très simple, il aurait étépossible d’être encore plus générique mais ce n’était pas le but recherchéici. Ajouter des fonctions supplémentaires voire une utilisation d’un fichierXML pour réduire le nombre d’opérations relatives à l’ajout d’une vue n’apas semblé être nécessaire du fait qu’un tableau blanc avec Flash et HTML5Canvas permet déjà de couvrir la quasi-totalité des utilisateurs potentiels.Néanmoins, cela reste possible et les opérations à effectuer sont loin d’êtrecompliquées.

La fonction générique d’initialisation d’une vue commence par appeler unefonction clear() sur cette vue. Celle-ci a pour but d’effacer toutes les don-nées que la vue pourrait contenir, de l’initialiser ou la réinitialiser. En effet,lors de plusieurs changements de vue, les fichiers téléchargés ne seront paschargés plusieurs fois et ce pour des raisons d’efficacité. Dès lors, des struc-tures de données ont besoin d’être vidées. En effet, étant donné que seulela vue affichée et ses données sont modifiées par le contrôleur, des change-ments multiples de vue auraient pu conduire à l’utilisation de structures dedonnées non mises à jour, ce qui aurait pu provoquer un affichage inadaptéà l’utilisateur. L’appel à la fonction clear() va donc vider ses structures dedonnées afin d’éviter ce problème.

Paramétrage (couleur et épaisseur)

Le paramétrage regroupe différentes données que les outils du tableaublanc utiliseront, comme la couleur ou l’épaisseur du crayon. Comme déjàdit, le choix a été pris de sauvegarder ce type d’informations et non del’envoyer à chaque fois pour des raisons d’efficacité. Le contrôleur mémorisedonc ces informations et appelle des fonctions sur les vues lorsqu’elles sontmises à jour.

58

Coordonnées X et Y

Cela aurait été pratique de disposer facilement des coordonnées X etY de la souris lorsqu’un évènement se produit (souris enfoncée, déplacée ourelâchée). Hélas, l’accès direct à ses coordonnées ne peut s’opérer sur tous lesnavigateurs. Une technique a été mise au point pour résoudre ce problèmede compatibilité. Celle-ci consiste à prendre la coordonnée de la souris parrapport à l’écran, puis d’y ajouter le décalage en pixels si l’utilisateur a défilédans la page (scrolling) et enfin de soustraire la coordonnée de la positiondu tableau blanc. C’est complexe effectivement mais cela a le mérite d’avoirexactement le même résultat sur tout navigateur qu’il soit récent ou non.

Outils (crayon et gomme)

La gestion des outils a été pensée de manière à pouvoir accueillir aisémentde nouveaux outils. En effet, en plus de l’outil particulier qu’est le Displayer,seuls deux outils ont été implémentés, un crayon et une gomme. C’est peumais c’est suffisant pour offrir un tableau blanc digne de ce nom. D’autresoutils peuvent être utiles, comme un outil pour dessiner simplement desformes, un fluo ou encore un outil pour écrire sur le tableau blanc avec lestouches du clavier. C’est pourquoi, l’ajout de nouveaux outils a été simplifié.

Il convient tout d’abord de définir ce qu’on entend par outil pour le tableaublanc. Il s’agit d’une option que l’utilisateur peut activer et qu’il pourrautiliser à l’aide de sa souris. Un outil est dit utilisé aussi longtemps quel’utilisateur garde sa souris enfoncée. Une limitation est qu’un seul outil peutêtre utilisé à la fois mais cela n’en est pas vraiment une puisque l’utilisateurn’a qu’une souris normalement. L’outil se doit définir des actions à effectuerpour trois évènements sur la souris, la souris enfoncée, le déplacement lorsquela souris a été enfoncée et la souris relâchée. Cela peut se traduire de manièreplus abstraite par le début de l’utilisation, l’utilisation effective et la fin del’utilisation de l’outil. Notons qu’un déplacement de souris revient à ce quele navigateur appelle une fonction d’interception avec des coordonnées X etY de manière régulière. Le nombre d’appels à cette fonction dépend de lacapacité du navigateur et de la machine du client.

La figure 4.6 illustre l’architecture logicielle de la gestion des outils dutableau blanc. Le choix a été d’utiliser un concept clé de la programmationorienté objet, une interface et plusieurs classes qui l’implémentent. Chaqueoutil est donc une classe implémentant WhiteBoardTool. Cette interfacecontient trois méthodes pour les trois évènements liés à la souris présentédans le paragraphe précédent. Chaque méthode a besoin de la coordonnéeX et de la coordonnée Y de la souris en pixels et en prenant pour point

59

de référence le tableau blanc (calcul effectué avec la méthode expliquée en4.3.2).

Figure 4.6 – Architecture des outils du tableau blanc

Notons que l’outil Displayer déjà présenté dans ce mémoire n’apparaîtpas car il ne répond pas à la définition d’outil pour tableau blanc donnéeplus haut. En effet, le Displayer est particulier dans la mesure où il est ditutilisé lorsque la souris n’est pas enfoncée et donc lorsqu’aucun outil pourtableau blanc n’est employé.

L’outil crayon fonctionne comme un ensemble de points reliés entre eux.Un chemin est ainsi dit tracé et il est nécessaire de savoir quand il commenceet quand il termine. Cela apporte une limitation qui fait que l’outil ne peutêtre utilisé par deux personnes au même instant, car les points reliés entreeux n’auraient plus de signification. La solution est de dessiner plusieurschemins différents, un par utilisateur. Mais cette solution apporte un lotde difficultés à prendre en compte car une vue ne peut gérer simplement letraçage de plusieurs chemin simultanément. Concrètement, il faudrait mettreau point un système de calques qui se superposent et les tracés simultanésseraient opérés sur des calques différents. Cela n’a pas été réalisé car celan’a pas été considéré comme une priorité. Il est en effet relativement peufréquent que plusieurs personnes aient besoin de dessiner au même instantsur un tableau blanc dans une réunion. Mais il faut savoir reconnaître qu’ils’agit bien là d’une limitation du tableau blanc qui est d’ailleurs mentionnéedans le manuel en annexe.

4.3.3 Implémentation des vues

L’implémentation des vues s’est faîte en parallèle, de manière à les gar-der au même niveau. Ainsi, lorsqu’une fonctionnalité était ajouté dans unevue, elle l’était ensuite dans l’autre. C’est principalement à partir de deuxtutoriels, l’un de Mozilla ([28]) et l’autre d’Opera ([29]), plus d’un livre ([31])que ce travail a pu être facilité. A ces références s’ajoutent bien sûr la docu-mentation officielle pour HTML5 Canvas ([39]) et celle pour Action Script3 ([34]). Les principes étant les mêmes entre ces deux technologies, il étaitsouvent aisé de trouver un équivalent dans la documentation pour Flash.

60

Vue en HTML5 Canvas

Un commentaire important à donner pour cette vue concerne la com-patibilité avec Internet Explorer (versions 6 à 8) et l’émulation réalisée parExcanvas ([26]). Une limitation reconnue par les développeurs de cette li-brairie empêche de pouvoir créer un véritable outil gomme pour le tableaublanc. Le mieux à faire est donc d’ajouter une couche de blanc, avec l’effetnégatif d’effacer aussi le slide s’il y en avait un en-dessous, ce que ne devraitpas faire une gomme. Dès lors, l’utilisation de cette vue pour une personneutilisant Internet Explorer (versions 6 à 8) est à éviter car non seulementil y a un manque clair de réactivité dû à l’émulation mais en plus le com-portement de la gomme peut avoir un effet indésiré. Heureusement, la vueFlash ne posera aucun problème pour les utilisateurs de ce navigateur.

Vue en Flash

La vue en Flash apporte un peu plus de complexité au niveau du dévelop-pement du fait que l’outil gomme ne peut être créé lorsque la forme utiliséeest vectorielle. Or, le tracé d’un chemin implique l’utilisation de forme vecto-rielle. La solution pour remédier à ce problème consiste à utiliser une formevectorielle temporaire qui est recopiée sur une forme bitmap dès le momentoù l’utilisateur relâche sa souris, autrement dit dès qu’un chemin a été tracé.L’utilisation de la gomme étant possible sur la forme bitmap, le problèmede cet outil est résolu. La vue en Flash se comporte ainsi normalement. Deplus, un lissage est effectué sur la forme bitmap, ce qui améliore son renduen plein écran.

Une autre difficulté qui a dû être réglée concerne la modification du cur-seur lors de l’utilisation d’un outil. En effet, l’utilisation de HTML / Javas-cript / CSS permet une modification du curseur qui sera gérée nativementpar le système d’exploitation. Pour Flash, il faut émuler ce changement encréant un objet qui suit la souris et en masquant la souris. Le mot ému-lation peut laisser penser à une diminution de qualité mais celle-ci n’estpas visible en utilisation normale. Pour ce qui est de l’implémentation decette émulation, la classe CustomCursor a été créée à cet effet et chaquecurseur personnalité est un objet de cette classe. Les méthodes de l’objetpermettent de montrer l’objet, le cacher ou le faire déplacer afin qu’il suiveles mouvements de la souris.

Concernant le mode plein écran, une lecture attentive d’un article d’Adobe(voir [37]) fût intéressante pour comprendre comment cela a été pensé afind’éviter une utilisation abusive de ce mode. Cela serait d’ailleurs pratiqueque ce mode soit utilisable directement en HTML, notamment pour les vi-déos mais aussi des applications Web comme c’est le cas dans ce mémoire.

61

Dans l’article, il est ainsi précisé que ce mode ne peut s’activer qu’après unclic de l’utilisateur. Cela évite de se retrouver en plein écran sans le vouloir.Cela a donc demandé d’ajouter un bouton dans le coin supérieur gauche dela vue pour que l’utilisateur puisse activer ce mode. L’article parle aussi demesures de sécurité comme l’affichage d’un message expliquant à l’utilisa-teur comme quitter ce mode et la touche Escape du clavier qui permet desortir de ce mode. Enfin, une autre limitation concerne l’usage du clavier.Afin d’éviter que quelqu’un se servirait de ce mode pour reprendre le mot depasse d’un utilisateur par exemple, les seules touches du clavier utilisablessont les quatre flèches directionnelles et la barre d’espace. Cela correspondheureusement aux seules touches nécessaires à intercepter pour le tableaublanc.

62

Chapitre 5

Développement de lavidéoconférence

L’outil de réunions comporte déjà un tableau blanc collaboratif, une ges-tion de la communication entre les différents participants et un petit espacede discussion en mode texte. Cela constitue déjà une base intéressante pourréaliser une réunion en ligne. Néanmoins, l’ajout de la vidéoconférence per-met d’augmenter grandement les possibilités de ce type de réunions. En effet,l’audio va permettre de pouvoir donner une explication plus simplement etplus rapidement sans avoir besoin de tout taper au clavier. Quant à la vidéo,elle permet d’une part d’ajouter un certain confort presque similaire à uneréunion classique et d’autre part de pouvoir montrer un document papiersans avoir besoin de le scanner au préalable.

Il y a donc un véritable intérêt à intégrer un module de vidéoconférence ausein de l’outil. L’intégration dans l’outil est quelque chose d’important afin dedonner à l’utilisateur une seule interface cohérente regroupant les différentsservices et d’éviter de devoir ouvrir différents logiciels sur l’ordinateur del’utilisateur en plus de son navigateur. C’est pourquoi des solutions commeEkiga ou Skype ne seront pas utilisés. Il faut néanmoins reconnaître qu’il ya un véritable travail de fond sur ces logiciels pour compresser au mieux lesdonnées échangées.

Les deux sections qui suivent vont donc apporter une justification surles choix de technologies qui ont été pris pour ce module, en distinguantbien la partie client de la partie serveur. Rappelons que l’utilisation dupair à pair (peer to peer) n’est pas acceptable étant donné qu’une réunionregroupe plusieurs utilisateurs et que cela demanderait à un client d’envoyerces données audio et vidéo à chaque autre personne. La bande passante endébit montant allouée par les fournisseurs d’accès à Internet est souvent trèsfaible et rend donc préférable l’utilisation d’une machine serveur qui jouera

63

le rôle de relais et qui sera connectée à un bon débit. Pour information,les tests ont été effectués sur un serveur enregistré chez OVH où la bandepassante allouée est de 100 Mbps.

5.1 Intérêt de Flash pour la partie clientL’envoi de l’image de la webcam et du son du microphone dans une so-

lution intégrée dans une page Web devrait idéalement pouvoir se produiresans nécessiter d’installation particulière et sans nécessiter un plugin surson navigateur. Hélas, cela n’est pas encore possible en 2010. Mais le WorldWide Web Consortium (W3C) commence à s’y intéresser en ajoutant unenouvelle balise au langage HTML dénommée Device. Les spécifications four-nies disponibles en ligne ([40]) sont modifiées de jour en jour. Mais commeon peut le lire, il reste encore beaucoup de travail pour avoir une spécifica-tion claire et complète. Ensuite, il faudra que les navigateurs implémententces nouvelles spécifications. Cela risque donc de prendre plusieurs mois voireplusieurs années avant qu’un tel service soit utilisable.

Un article publié le 29 juin 2010 sur le blog officiel du site de vidéos You-tube 1 explique leur motivation à utiliser la plateforme Flash pour la vidéoet souligne le problème d’accès à la webcam et au microphone : Video is notjust a one-way medium. Every day, thousands of users record videos directlyto YouTube from within their browser using webcams, which would not bepossible without Flash technology. Camera access is also needed for featureslike video chat and live broadcasting - extremely important on mobile phoneswhich practically all have a built-in camera. Flash Player has provided richcamera and microphone access for several years now, while HTML5 is justgetting started. (John Harding, blog officiel de Youtube).

Comme c’est précisé dans cet article, Flash dispose d’API très simples àutiliser pour l’accès à ce type d’appareils et du fait de l’expérience acquisedepuis plusieurs années, la compatibilité avec les webcams est très impor-tante et cela aussi bien sur Windows, Mac OS, Linux et Solaris. Le taux depénétration de Flash qui avoisine les 100% se rajoute aux arguments pourcette technologie par rapport aux plugins concurrents. Ajoutons encore quele travail sur la plateforme Flash pour cet usage a été conséquent ces der-nières années avec par exemple le projet Adobe Stratus qui a rendu possiblel’usage du pair à pair dans le navigateur. C’est grâce à ce projet qu’un étu-diant russe, Andreï Ternovsky, a créé le buzz avec son site Chatroulette.comà la fin de l’année 2009. Ce site propose de la vidéoconférence avec un par-tenaire aléatoire et cela avec une simplicité d’utilisation remarquable. Eneffet, il suffit d’un clic pour autoriser l’accès à la webcam et au microphone

1. Voir : http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html

64

pour se retrouver directement connecté avec une autre personne, sans avoirdû procéder à une installation particulière ou à remplir un formulaire d’ins-cription.

C’est pour ces différentes raisons que Flash a été choisi, avec son proto-cole, le RTMP (Real Time Messaging Protocol), dont les spécifications sontdonnées officiellement par Adobe (voir [36]).

5.2 Intérêt de HaxeVideo pour la partie serveurIl existe plusieurs serveurs pour utiliser le protocole RTMP, le plus connu

étant celui vendu par Adobe, le serveur Adobe Flash Media Server. Maiscomme souvent, il existe des alternatives gratuites et open-source qui ontpour avantage supplémentaire d’être plus maintenables et de permettre lamodification du code source pour l’adapter à ses besoins.

RED5 est le serveur open-source le plus connu pour cet usage mais il estassez lourd du fait qu’il implémente presque toutes les fonctions de FlashMedia Server. Une autre solution open-source a été créée par Nicolas Can-nasse, l’auteur de HaXe et se dénomme tout simplement HaXeVideo (voir[5]). Il utilise la plateforme Neko VM qu’il a lui-même développée et qui seveut très légère : haXeVideo is an multithread FLV streaming server enti-rely written using the haXe programming language. The source code is verysmall and the server is lightweight (both CPU and memory) but very scalable(Nicolas Cannasse). Le serveur HaxeVideo est limité dans ses fonctionnali-tés mais convient parfaitement pour l’usage qui en est fait dans l’outil deréunions en ligne. Un point intéressant pour ce serveur est qu’à l’instar desdifférents modules de ce mémoire, le code de ce serveur se veut maintenableet extensible.

5.3 Développement du modulePour ce qui est de la partie serveur, aucun développement n’a été effectué,

le serveur HaXeVideo a été repris tel quel. Il aurait pu être intéressant dechercher à optimiser davantage ce serveur mais cela sortait du cadre dece mémoire. C’est donc uniquement la partie client qui a été développéeen utilisant les API d’Adobe. Cette section va donc d’abord expliquer lagestion d’un ensemble de vidéos, puis l’envoi de la vidéo, sa réception etenfin elle détaillera le système de gestion de places privilégiées par le serveurWebSocket.

65

5.3.1 Gestion des vidéos

La gestion des différentes webcams affichées est réalisée par un contrô-leur unique totalement en Javascript, dont le code se retrouve dans le fichierWebcamsManager.hx. Chaque webcam est ainsi un objet de la classe Web-cam, qui contient les méthodes nécessaires à la bonne communication entreFlash et Javascript, comme déjà expliqué dans les chapitres précédents. Laclasse WebcamsManager contient ainsi une structure de données regroupantces objets de la classe Webcam et contient des méthodes pour ajouter ousupprimer une webcam.

5.3.2 Envoi de la vidéo

L’implémentation de l’envoi de l’image de la webcam et du son du mi-crophone se retrouve dans le fichier WebcamSender.hx, qui génère un fichierFlash (SWF). Il est intéressant d’expliquer le fonctionnement pensé poursimplifier la démarche pour l’utilisateur. En effet, dans l’interface apparaîttout en haut un lien Envoyer ma webcam. Un clic sur ce lien fait alors ap-paraître ce fichier Flash qui ne sera donc téléchargé que lorsque cela estnécessaire. Visuellement, l’objet Flash ajouté dans la page est une petitefenêtre qui permet à l’utilisateur de sélectionner sa webcam puis de donnerson accord pour que les données soient envoyées.

Dès que l’utilisateur a fait son choix, l’objet Flash demande au contrôleurJavascript de masquer l’objet Flash, donc de se masquer lui-même et dansle même temps indique si ou non l’utilisateur a accepté. En cas de refus,un message d’erreur est affiché et le lien pour envoyer sa webcam est denouveau visible pour que l’utilisateur puisse réessayer. En cas de problèmede connexion au serveur RTMP, le principe est le même, le message d’erreurest juste différent. Par contre, en cas d’acceptation et de bonne connexion auserveur, l’objet Flash et le lien d’envoi sont masqués, puis le WebSocketClientest chargé d’envoyer un message à tous les clients pour leur prévenir de ladiffusion d’une webcam.

Etant donné que le modèle client - serveur pour la vidéo crée un petit délaiestimé à une seconde, le client qui envoie sa webcam voit dans l’interfacel’image reçue par les autres participants. Le son ne lui est pas répliqué pourdes raisons évidentes de s’entendre en écho, ce qui serait fort désagréable. Parconte, pouvoir voir son image telle qu’elle est reçue par les autres utilisateursest intéressant pour pouvoir observer le délai de retransmission et savoirexactement ce que les autres voient au moment présent.

66

5.3.3 Rception de la vidéo

La réception de la vidéo se passe donc par le contrôleur Javascript quigère les différents objets Flash servant à la réception de la vidéo. En effet,chaque vidéo reçue correspond à un objet Flash. C’est donc le système d’ex-ploitation qui se charge du rendu audio et vidéo simultané. Cette manièrede procéder prépare le terrain pour une évolution de ce module lorsqu’il serapossible de le faire totalement en HTML5.

L’implémentation d’un receveur de webcam se trouve donc dans le fichierWebcamViewer.hx. C’est l’objet Flash lui-même qui détecte l’activité de lapersonne. Détecter l’activité d’un participant est quelque chose qui a étémûrement réfléchi et qui a d’ailleurs été présenté précédemment (voir 2.4.2).Afin d’éviter d’ajouter des messages supplémentaires sur le canal de com-munication WebSocket, c’est donc l’objet Flash de lecture d’une vidéo quianalyse le son reçu et informe Javascript de l’activité d’un client. Concrète-ment, toutes les 500 millisecondes, l’objet Flash regarde le nombre d’octetsreçus pour l’audio dans la seconde qui précède et selon ce nombre, il informeJavascript de l’activité ou non du client.

Enfin, une petite fonctionnalité pratique qui a été ajoutée est le pleinécran. En effet, il suffit de cliquer sur la vidéo d’un participant pour voircelui-ci en plein écran. Cela peut être pratique si ce participant utilise sawebcam pour montrer un objet à l’écran par exemple.

5.3.4 Gestion des places privilégiées

Dernier point à présenter et non des moindres, il s’agit de la gestion desplaces dîtes privilégiées, déjà présentée précédemment (voir 2.4.1). Pour rap-pel, c’est le serveur WebSocket qui décide de manière heuristique quand est-ce qu’un changement de places doit être effectué. Pour prendre ses décisions,il a bien sûr besoin de données, et c’est l’objet Flash d’envoi de la Webcamqui va les communiquer à Javascript pour que celles-ci soient transmises auserveur WebSocket. Ces données sont simplement l’activité du microphone,valeur comprise entre 0 (muet) et 100 (utilisation maximale).

Afin d’avoir des données pertinentes mais de ne pas surcharger davantagele canal de communication WebSocket, le choix a été que Flash effectue unemesure toutes les 200 millisecondes puis calcule lui-même une moyenne deces mesures après 2 secondes. C’est cette moyenne qui sera communiquée auserveur WebSocket toutes les deux secondes, ce qui reste raisonnable quantà l’utilisation du canal de communication WebSocket.

67

Un point reste à définir, il s’agit de la petite intelligence artificielle setrouvant dans le serveur WebSocket pour la décision de placement des inter-venants. Ce paragraphe discute donc de code inséré dans le fichier server.php.C’est de nouveau l’orienté objet qui a été choisi et c’est ainsi que chaqueplace privilégiée est un objet de la classe Place. Deux constantes sont défi-nies pour le minimum d’activité requise pour que l’utilisateur soit considérécomme en train de parler et le temps minimum qu’une personne reste à uneplace.

La première constante permet de ne pas fausser le raisonnement automa-tique avec des valeurs non pertinentes. En effet, le simple fait de respirerconstitue une activité mais qui ne représente rien pour ce système de placesprivilégiées. La limite a été fixée à 15, sachant que lorsqu’on parle douce-ment, cela reste au-delà de 20. Le nombre de 15 est donc une bonne valeur,qui peut être modifiée dans le fichier si le besoin se fait sentir. Pour ce quiest de la durée minimale, le but est d’évite des changements trop réguliersqui perturberaient l’utilisateur plus qu’autre chose. La valeur définie pourcette constante est de 15 secondes.

Un objet de la classe Place contient une référence vers un objet de la classeWebSocketUser, le moment auquel lequel l’utilisateur en question a obtenula place, le dernier niveau d’activité reçu par le serveur WebSocket et enfinle numéro de la place.

Lorsqu’une valeur d’activité est reçue par le serveur WebSocket, la fonc-tion receiveActivityLevel($user, $msg, $server) est appelée. Cettefonction utilise l’heuristique suivante. Tout d’abord, elle teste deux cassimples. Le premier est qu’une place privilégiée est libre. La fonction vamettre l’utilisateur à cette place. Le second cas est que le message reçu pro-vient d’un utilisateur se trouvant déjà à une place privilégiée. La fonctionva alors simplement mettre à jour le niveau d’activité de l’utilisateur. Dansles deux cas, le traitement s’arrête là.

Après avoir testé ces deux cas simples et si on ne se retrouve pas dansun de ces cas, autrement dit que les places privilégiées sont occupées etque le message reçu correspond à un utilisateur qui n’est pas à une placeprivilégiée, il faudra là prendre une décision quant à l’utilisateur pour lequelle message a été reçu. Tout d’abord, le niveau d’activité reçu est comparéau niveau minimal requis et s’il est inférieur, la fonction s’arrêtera là, il n’yaura donc pas de changement de place.

Si le niveau est bien supérieur au niveau requis, l’algorithme consiste àrechercher une place pour laquelle le dernier niveau d’activité enregistré est

68

inférieur au niveau reçu dans le message et qui n’a pas été attribuée troprécemment, selon la valeur de la constante définissant le temps minimal àune place. Lorsque plusieurs places répondent à ces deux conditions (tempsminimal et activité minimale), l’heuristique consiste à préférer la place quia été attribuée le moins récemment. C’est donc le critère de temps à uneplace qui est privilégié sur le critère de la personne qui parle le plus fort.Cela permet en outre d’assurer une meilleure rotation des participants pources places privilégiées.

Remarque Ce système de changement de places avait aussi initialementpour but de réduire le nombre d’images par secondes envoyées au serveurlorsqu’un participant se trouvait en place standard. En effet, cela auraitpermis de réduire l’utilisation de la bande passante pour l’envoyeur, pourles receveurs et pour le serveur. Cependant, contrairement à ce qui avaitété pensé erronément, il n’est pas possible de changer la qualité sans devoirarrêter la diffusion puis la reprendre. Cette limitation rendait l’objectif bienplus difficile à atteindre si l’on souhaite conserver une bonne expérienceutilisateur sans coupures de son ou d’image. Cet objectif n’a donc hélas paspu être atteint.

69

Chapitre 6

Intégration dans Claroline

L’intégration dans Claroline a été la dernière partie développée maiscela ne signifie pas une négligence de cette intégration. Celle-ci a en effet étépensée pour s’adapter à la charte graphique de la plateforme et une étudesur l’architecture de Claroline a été réalisée afin de pouvoir offrir un produità la communauté qui respecte les attentes de l’équipe de Claroline.

Ainsi, les conventions de codage et les conseils liés à la sécurité ont étérespectés en majeure partie dans les fichiers PHP et dans la connexion avec labase de données utilisée par Claroline. L’intégration à Claroline ouvre aussiune nouvelle dimension à cet outil avec la gestion d’un ensemble de réunionscomprenant ajout, modification et suppression. Notons que cette gestionest assez basique mais son évolution a déjà été imaginée. Cela pourrait alorsdevenir un véritable gestionnaire de réunions, en ligne ou non, qui faciliteraitl’organisation de celles-ci pour le professeur.

6.1 Définition d’un module Claroline et choix liésCette section a pour but de présenter comment la plateforme Claroline

permet la création de nouveaux outils qui permettraient de l’enrichir aisé-ment. Elle a aussi pour but de présenter les différents choix entrepris parrapport aux multiples possibilités offertes par la plateforme.

La plateforme Claroline contient une gestion performante pour la créationde nouveaux outils et a ainsi introduit la notion de module Claroline. Unmodule Claroline peut être un applet, c’est-à-dire un petit script léger dontl’affichage est limitée dans une zone réservée (docks), mais aussi un outilpour enrichir l’administration de la plateforme ou encore un outil qui vients’ajouter aux outils d’un cours (agenda, annonces, travaux, ...) et / ou auxoutils disponibles à un groupe d’utilisateurs d’un cours. Dans ce mémoire,l’application développée constitue un nouvel outil pour un cours. Le but

70

n’étant pas d’ajouter des scripts légers ni de modifier l’administration dela plateforme, c’est donc en tout logique le choix le plus cohérent. Il seraitintéressant que l’outil soit aussi un outil pour les groupes d’un cours, et celasera d’ailleurs discuté plus tard dans ce chapitre.

Techniquement, tout a été pensé pour que cela soit très simple pour ledéveloppeur de créer un module. En effet, c’est à l’aide d’un fichier XML,appelé le manifest, que le développeur renseigne les informations liées à sonmodule. Ensuite, il lui suffit de créer une archive ZIP qui contient son fichierXML plus ses autres fichiers pour que le module soit installable en quelquesclics pour l’administrateur de la plateforme. Il y a bien entendu certainesrègles à respecter pour que l’outil développé s’intègre bien dans la plateformeet accède proprement aux données qu’il a besoin, mais la documentationfournie les explique clairement.

Le fichier XML contient donc les données nécessaires pour que Clarolinepuisse installer et exécuter le module de façon automatisée. Ces donnéescomprennent entre autres un identifiant unique du module développé, letype de module (applet, outil pour l’administration ou encore outil pourcours et groupes) et le nom du module. D’autres informations facultativespeuvent être ajoutées, telle une description du module, des renseignementssur son ou ses auteurs, la version, les dépendances ou encore la licence dumodule.

Une remarque qui me semble constructive pour Claroline serait de per-mettre de définir plusieurs noms de modules selon les langues gérées par lemodule. En effet, pour que le nom du module s’affiche dans la bonne languedans la liste des outils d’un cours, il faut faire une modification dans unfichier central de Claroline. Cependant, il faut reconnaître que la gestiondes différentes langues pour les fichiers d’un module est vraiment bien pen-sée. C’est donc juste pour le nom du module qu’une amélioration à ce sujetpourrait être envisagée.

Un module a en outre la capacité d’utiliser la base de données de Claro-line mais un choix important est à effectuer par le développeur du module.En effet, Claroline utilisant une table pour chaque cours, le développeur a àchoisir s’il souhaite suivre ce modèle ou bien utiliser une seule table généraledans laquelle il différencie lui-même les données par rapport aux cours utili-sant le module. C’est la seconde option qui a été préférée car elle s’avère plusdans la philosophie des bases de données relationnelles et lors d’une main-tenance, une seule table devra être mise à jour et non plusieurs. Un index(au sens d’index dans une table d’une base de données) a été défini sur lecode du cours afin de pouvoir lister les réunions quasiment aussi rapidement

71

que s’ils étaient séparés dans plusieurs tables. Ce choix reste discutable et apour impact que toutes les données liées au module devront rester dans uneseule table et donc une seule base de données.

6.2 Respect des conventions de codage et autresconseils

Différents documents (principalement [10] et [13]) constituent une vé-ritable aide pour toute personne souhaitant développer pour la plateformeClaroline. La documentation donne de précieux conseils pour que le moduleréalisé soit maintenable et sécurisé, en présentant les conventions de codageutilisées par la plateforme.

Qu’il s’agisse des alignements et tabulations, du nommage des fonctions etdes variables, de la structure d’un module Claroline ou des conseils quant à lasécurité vis-à-vis des injections SQL, une attention particulière y a été portéeafin que le module soit construit en respectant ces recommandations. Demême, les fichiers PHP du module sont bien commentés, en anglais commeconseillé dans la documentation.

Il est par exemple intéressant de citer le cas des variables du module quel’administrateur de la plateforme peut modifier. Claroline apporte là uneaide vraiment bien pensée pour pouvoir définir des variables de configurationet Claroline se charge alors de créer une interface utilisateur automatique-ment pour que le responsable de la plateforme puisse modifier ces donnéesaisément.

Un autre bénéfice apporté par Claroline concerne les boîtes de dialogues,permettant d’afficher un message de confirmation, ou d’erreur, ou encore unformulaire dans un petit cadre standardisé pour la plateforme. Là aussi, ilest vraiment simple pour le développeur d’en faire usage.

6.3 Présentation détaillée du module ClarolineL’outil de réunions marie différentes technologies, du Flash (SWF), du

Javascript, du PHP et du HaXe comme source pour Javascript et PHP.La documentation de Claroline fournit des indications claires pour aiderà produire un module avec une structure de fichiers visant à ce que lesdifférents fichiers soient bien classés et facilement repérables pour quelqu’und’extérieur au développement du module.

72

La figure 6.1 présente visuellement la structure de fichiers du moduleClaroline, composée de trois fichiers et neuf dossiers.

Figure 6.1 – Structure de fichiers du module

Voici quelques informations au sujet de ces fichiers et dossiers :– manifest.xml C’est le fichier XML utilisé par Claroline pour installeret exécuter correctement le module.

– index.php Il s’agit là du fichier PHP qui représente le point d’entréedu module. A l’aide de librairies développées pour ce module, il peutafficher la liste des réunions et prendre en charge les opérations sur lesréunions, à savoir l’ajout, la modification et la suppression.

– onlineMeeting.php Ce fichier PHP construit la page Web pour l’ap-plication de réunion en ligne, en se basant aussi sur des librairies dé-veloppées pour ce module.

– icon.gif Ce fichier est l’icône du module et représente trois utilisa-teurs et une table ronde, à l’image d’une réunion classique.

– conf Ce dossier contient un dossier def contenant lui-même un fi-chier PHP servant à définir proprement les variables de configurationdu module. C’est grâce à ce fichier que Claroline génère un formu-laire dans l’espace d’administration pour mettre à jour ces variables.Concrètement, le module utilise deux variables, l’une pour l’URL du

73

serveur WebSocket et l’autre pour l’URL du serveur RTMP pour lavidéoconférence. Notons que s’il n’y a pas de serveur RTMP précisé,la vidéoconférence sera simplement désactivée.

– css Il s’agit du dossier contenant un seul fichier CSS pour la mise enpage de l’application de réunion en ligne. Cependant, il définit princi-palement le placement des éléments dans la page car les couleurs, tailleet police d’écriture et autres informations liées à la charte graphiquesont celles que le gestionnaire de la plateforme a choisies ou celles dé-finies par défaut par Claroline. Cela permet une meilleure intégrationde l’outil dans la plateforme Claroline.

– img Cinq fichiers d’image se retrouvent dans ce dossier. Il y a le crayonet la gomme qui sont les curseurs pour le tableau blanc lorsqu’un de cesoutils est utilisé. Ils sont définis sous deux formats d’image différents(gif et cur) en raison des formats acceptés par les navigateurs commecurseur de remplacement. Le cinquième fichier d’image est en PHP.En effet, c’est le curseur flèche pour l’outil Displayer dont la couleurvarie selon l’utilisateur. Afin d’avoir une solution propre et générique,c’est donc un fichier PHP qui génère une image à la volée selon unparamètre de couleur.

– js Conformément à la documentation de Claroline, ce dossier regroupeles différents fichiers Javascript utilisés. Rappelons que ceux-ci ont étégénérés à partir de HaXe, à l’exception des librairies Javascript utili-sées que sont getPos [25] et Excanvas [26]. La librairie JQuery n’a pasbesoin de se trouver dans ce dossier, celle-ci étant dans les librairiesJavascript gérées par Claroline. Un simple appel dans le code sourcepermet donc dans l’inclure dans une page Web.

– lang Le module a été traduit en français. Ce dossier inclut un fichieravec les traductions que Claroline pourra utiliser pour afficher des ex-pressions en français si la langue du cours est le français. Dans le cascontraire, les différents textes seront affichés en anglais.

– lib Ce dossier contient les librairies PHP utilisées par les fichiers in-dex.php et onlineMeeting.php. Trois librairies sont ainsi définies, unepour les opérations sur les données, une autre pour l’affichage et unedernière pour la validation des données de formulaires.

– setup Il s’agit du dossier contenant les fichiers SQL que Clarolinepeut exécuter. Dans le cas de ce module, il y a donc un fichier pourl’installation du module dans la plateforme et un autre pour sa dés-installation.

74

– src Ce dossier s’ajoute à ceux définis dans la documentation de Cla-roline. En effet, pour Flash et ici même pour Javascript, il existe desfichiers source. Le projet de ce mémoire étant open-source, ajouter lessources à la structure du module est donc justifié et nécessaire pourtoute personne souhaitant travailler par après sur ce module. Notonsqu’il contient un fichier compile.hxml qu’il suffit de lancer en ligne decommande, avec HaXe installé, pour que le compilateur de HaXe gé-nère les différents fichiers et se charge de les placer automatiquementdans les dossiers appropriés.

– swf A l’instar du dossier js, ce dossier regroupe les fichiers Flash(SWF) utilisés et générés à partir des fichiers HaXe.

A ces dossiers et fichiers représentant l’archive ZIP d’un module Claroline,deux autres dossiers de fichiers sont utilisés. L’un pour le serveur WebSocketet l’autre pour le serveur RTMP HaXeVideo. Ces deux serveurs peuvent setrouver sur toute machine connectée à Internet (leur URL étant renseignéedans les variables de configuration) mais de préférence sur une machine dontla bande passante est élevée, en débit montant comme en débit ascendant.

6.4 Développement du moduleLes chapitres précédents ont permis d’expliquer le développement de

l’outil de réunion en ligne. La partie ajoutée pour Claroline est le fichieronlineMeeting qui permet l’intégration de l’outil à Claroline ainsi que lagestion d’un ensemble de réunions avec ajout, modification et suppressionde celles-ci. Cette section va donc s’intéresser exclusivement aux fichiersPHP du module Claroline et à ce qui a été ajoutée à la base de données deClaroline.

6.4.1 Base de données

Le module permet de gérer plusieurs réunions et celles-ci se retrouventenregistrées dans une table de la base de données de Claroline. Voici lastructure de cette table :

CREATE TABLE IF NOT EXISTS ‘__CL_MAIN__meetings‘ (‘id‘ int(11) NOT NULL auto_increment,‘courseCode‘ varchar(30) NOT NULL,‘title‘ varchar(80) NOT NULL,‘mainUserId‘ int(11) NOT NULL,‘date‘ date NOT NULL,‘startHour‘ time NOT NULL,

75

‘endHour‘ time NOT NULL,‘location‘ varchar(255) NULL default NULL,‘slidesPath‘ varchar(255) NULL default NULL,‘is_online‘ tinyint(1) NULL DEFAULT ’0’,PRIMARY KEY (‘id‘),INDEX (‘courseCode‘)

) ENGINE=MyISAM

Comme discuté précédemment, cette table est une table globale de Claro-line et possède donc un champ pour le code du cours. Ce champ est indexé demanière à ce que les requêtes qui filtrent sur ce champ soient accélérées. Lechamp mainUserId correspond à l’identifiant de l’utilisateur principal de laréunion qui est en fait enregistré comme tuteur dans Claroline. Pour rappel,cette personne aura une place centrale et fixe lors d’une réunion en ligne. Lechamp location est facultatif car une réunion peut se passer complètementen ligne. Pour ce qui est des slides, ils sont également facultatifs. Enfin, lechamp is online définit si la réunion se passe en ligne ou non.

Lorsque le gestionnaire d’un cours crée une réunion, un nouvel enregistre-ment s’ajoute à la table. De même lorsqu’il modifie une réunion, l’enregistre-ment concerné est modifié. Tous les champs peuvent être édités, à l’exceptionde l’identifiant unique et du code du cours bien sûr. Ces deux informationssont d’ailleurs insérées automatiquement lors de l’ajout d’une réunion. Encas de suppression d’une réunion, c’est l’enregistrement concerné qui esteffacé, sans avoir de soucis de dépendances puisqu’il n’y a qu’une table.

6.4.2 Librairies développées

Les deux fichiers PHP principaux se basent sur trois librairies, dont voiciune description de chacun d’elle.

Librairie d’affichage

Cette librairie a pour but de fournir des fonctions facilitant l’affichaged’informations dans la page Web, en ajoutant donc le code HTML lorsquecela est nécessaire. Notons cependant que chaque fonction renvoie une chaînede caractères à la fonction appelante. C’est donc à cette dernière de prendreen charge ou faire prendre en charge un affichage effectif dans la page Web.Exception faite pour la fonction displayError($message) qui affiche lemessage d’erreur en paramètre dans une boîte de dialogue de Claroline etarrête tout traitement PHP après son affichage. C’est donc une fonction àappeler lorsqu’une erreur importante est rencontrée, par exemple Javascriptdésactivé sur la page Web de réunion en ligne.

76

Il y a tout d’abord des fonctions pour l’affichage des boîtes ou cadres dansl’interface d’une réunion en ligne. En effet, chaque cadre est identique pourchaque utilisateur, avec parfois de petites variantes. L’utilisation d’un lan-gage de programmation tel que PHP permet d’éviter la duplication de codeHTML et permet ainsi d’avoir un code propre, générique et maintenable.

Ensuite, il y a une fonction pour l’affichage d’un tableau de réunions.Celle-ci demande en paramètre une liste de réunions à afficher et deux valeursbooléennes pour savoir si respectivement il faut ajouter des boutons pour quel’utilisateur puisse modifier ou supprimer une réunion, et s’il faut proposerl’accès en ligne lors la réunion est enregistrée comme pouvant se passer enligne. L’usage de cette deuxième variable consiste à ne pas afficher un liend’accès lorsque la réunion s’est déjà produite ou va se produire à une datefuture. Ainsi, les appels à cette fonction avec une liste de réunions passéesou futures aura ce paramètre à False alors qu’un appel avec une liste desréunions du jour aura ce paramètre à True.

Une autre fonction de cette librairie concerne l’affichage du formulaired’ajout ou de modification d’une réunion. C’est une seule fonction génériquequi traite ces deux situations. Cette fonction reçoit un paramètre avec les va-leurs à afficher dans les différents champs de texte. L’intérêt de ce paramètresera expliqué dans la section suivante.

Enfin, il y a une fonction pour obtenir un messsage d’erreur dans une boîtede dialogue concernant les données remplies par l’utilisateur dans un formu-laire. Cette fonction fait appel au validateur et peut alors créer une boîtede dialogue avec le message à afficher. Si les données rentrées sont correctes(titre non vide, date existante, ...), la fonction renverra alors null signifiantà la fonction appelante qu’il n’y a pas de message d’erreur à afficher, toutétant correct. Une dernière petite fonction concerne l’affichage d’une boîtede dialogue avec un message de résultat. La fonction prend en argument unevariable booléenne indiquant si le résultat est un succès ou non, puis deuxvariables pour le message à afficher en cas de succès et le message à afficheren cas d’erreur. Cette petite fonction est dès lors fort pratique par exemplelorsque l’on fait une requête SQL qui renvoie une variable booléenne de ré-sultat. En effet, il suffit de l’appeler avec cette variable et les deux messagespossibles pour que cela affiche le bon message à l’utilisateur.

Librairie d’opérations sur les données

C’est uniquement cette librairie qui a la responsabilité d’effectuer desrequêtes SQL sur la base de données. Elle dispose donc de cinq fonctions, unepour ajouter une réunion, une pour modifier une réunion, une autre encorepour supprimer une réunion et enfin deux fonctions permettant de récupérer

77

les informations portant sur un ensemble de réunions pour la première etsur une seule réunion via son identifiant pour la seconde.

Notons que la fonction pour récupérer un ensemble de réunions contientdes paramètres pour définir l’ordre des réunions. Il s’agit du nom d’un champsur lequel se fait le tri et d’une variable booléenne indiquant si l’ordre doitêtre ascendant ou descendant. Ainsi, l’utilisateur peut cliquer sur un titredans le tableau pour que le tri s’opère sur le champ correspondant au titresur lequel il a cliqué.

Un autre paramètre de cette fonction permet de filtrer la liste des réunionsrenvoyées. En effet, sur la page de gestion de réunions, il a été choisi d’affi-cher trois tableaux, le premier avec les réunions du jour, le second avec lesréunions à venir et le troisième avec les réunions antérieures. Cela apporteainsi une vue claire à l’étudiant et au professeur sur les réunions qui ontété ajoutées. Le paramètre filter permet donc de renseigner quelles réunionssont à récupérer, sa valeur peut ainsi être ’past’, ’today’, ’next’ ou ’all’.

Librairie pour la validations des données

Cette troisième et dernière librairie étend la classe DataValidator deClaroline. Elle a pour but d’ajouter deux règles à ce validateur. La premièreconsiste à vérifier que la date renseignée par l’utilisateur existe bien dansun calendrier et la seconde est une comparaison lexicographique de chaînesde caractères. Son intérêt est de pouvoir vérifier que l’heure de fin est bienaprès l’heure de début. Notons que cela empêche clairement d’avoir uneréunion qui se déroule en pleine nuit à l’intervalle entre deux jours. Maiscette limitation n’a pas été jugée problématique lorsque l’on compare auxréunions réelles qui se déroulent la plupart du temps en journée.

6.4.3 Gestion d’un ensembles de réunions

La gestion d’un ensemble de réunions est réalisée par le fichier index.phpet les librairies décrites dans la section précédente.

A l’instar des autres modules de Claroline, le paramètre cmd reçu avecune requête GET ou POST a pour but d’identifier la commande demandéepar l’utilisateur. Les valeurs possibles sont ’rqCreate’, ’rqEdit’, ’exCreate’,’exEdit’ et ’exRm’ pour respectivement l’affichage du formulaire de créationd’une réunion, l’affichage du formulaire d’édition d’une réunion, l’exécutiond’une création, d’une édition et d’une suppression. Un switch sur ce champpermet de réaliser les actions appropriées.

78

Il s’est alors posé la question de gérer efficacement et le plus simplementpossible les données d’une réunion dite en mouvement. Une réunion en mou-vement est une réunion qui va être ajoutée ou qui va être modifiée. En effet,si l’utilisateur a par exemple oublié de renseigner un titre pour une nouvelleréunion, il se crée une réunion en mouvement avec les autres informationsqu’il a remplies. Grâce à cette réunion en mouvement, il retrouve les valeursdéjà ajoutées dans les différents champs. De même lorsqu’il veut modifierune réunion, il faut que les champs du formulaire reprennent les informationscorrespondantes à la réunion qu’il veut modifier.

C’est ainsi qu’un tableau associatif global du nom de meetingInfos est créépar PHP, où chaque clé de ce tableau correspond à un nom de champ dela table de la base de données. Ce tableau est initialisé avec des chaînes decaractères vides sauf l’identifiant et le paramètre is online qui valent null.Ce tableau est mis à jour avec les informations de la base de données siun paramètre id a été reçu en GET ou POST. Ensuite, il est remis à jouravec les autres valeurs reçues en GET/POST s’il y en a. Ces valeurs enPOST/GET sont traitées au préalable afin d’éviter toute insertion de codemalveillant.

En procédant de la sorte, un invariant peut être déclaré sur cette variable.Celui-ci dit que ce tableau associatif contient toujours les informations lesplus à jour sur une réunion en mouvement. Grâce à cet invariant, ce tableauest utilisé pour remplir les champs du formulaire d’édition d’une réunion etpour remplir ce même formulaire ainsi que le formulaire de création d’uneréunion lorsqu’une erreur a été repérée par le validateur de données. Leschamps du formulaire auront comme le veut l’invariant les valeurs les plusà jour. Mais ce n’est pas tout, c’est ce tableau qui est passé aux fonctionsde la librairie gérant les opérations sur les données. Le fait que le nomdes clés corresponde au nom des champs permet de faciliter grandement laconstruction des requêtes SQL à partir de ce tableau associatif.

6.4.4 Accès à une réunion en ligne

Le deuxième fichier PHP important est onlineMeeting.php et crée lapage Web permettant d’accéder à une réunion en ligne. L’interconnexionavec Claroline se déroule de manière simple via des variables Javascriptglobales à définir. Cet ensemble de variables permet de facilement intégrerl’outil de réunion en ligne dans une autre plateforme si le besoin se faitsentir. Pour ce qui est de la sécurité, il faudrait définir une gestion desdomaines que le serveur WebSocket accepte. Ainsi, si un utilisateur copieet colle le code Javascript sur un autre site, il ne pourrait pas se connecterà la réunion en ligne car il est sur une page qui n’est pas sur le mêmeserveur que celui de la plateforme Claroline. Cela demande donc de modifier

79

la méthode doHandshake($buffer, $host) de la classe WebSocketUser duserveur WebSocket pour tester la valeur de la variable $headers[’Origin’].

Lorsque toutes ces variables Javascript sont définies, il faut après celainsérer les scripts Javascript nécessaires pour que la réunion en ligne soitopérationnelle. Claroline apporte des méthodes pour modifier la partie headde la page Web, ce qui permet donc d’insérer ces scripts dans cette partiede la page.

6.5 Améliorations envisageablesComme cela a été dit, ce mémoire est avant tout là pour offrir un ser-

vice de réunions en ligne. La gestion d’une liste de réunions est cependantfort utile pour que l’application soit vraiment intégrée dans Claroline. Cettegestion des réunions est très basque bien que suffisante. Afin d’améliorercette gestion des réunions, d’autres possibilités ont été envisagées mais nondéveloppées. Le but étant ici de simplement ouvrir la discussion car un déve-loppement de fonctionnalités additionnelles demande un travail conséquenten tenant compte que toute fonctionnalité ajoutée doit être pensée pour lamaintenance et que des tests importants doivent être effectués.

6.5.1 Envoi des slides intégré

La gestion des slides est assez pauvre étant donné que l’utilisateur doitlui-même les convertir en fichiers JPG de 600 x 464 pixels puis les placerdans un dossier adapté du répertoire de documents du cours. L’outil convertde ImageMagick permet en une ligne de commande appelable depuis PHPde convertir directement un fichier PDF en fichiers JPG avec les bonnes di-mensions et un taux de compression adéquat. Des tests ont été effectués maiscela n’a finalement pas pu être intégré car il y a encore un travail importantà réaliser afin que cela soit le plus simple possible pour l’utilisateur.

Concrètement, il faudrait ajouter un champ d’envoi de fichier dans le for-mulaire d’ajout ou de modification d’une réunion puis traiter correctementce champ côté serveur, assurer la sécurité vis-à-vis des fichiers envoyés, de-mander à ImageMagick de procéder à la conversion puis enfin placer lesfichiers convertis à l’endroit approprié. Cela n’est donc pas du tout impos-sible à réaliser, cela demande juste du travail supplémentaire pour que celasoit bien fait.

6.5.2 Gestion de réunions périodiques

Une fonctionnalité moins importante mais tout de même vraiment pra-tique serait d’intégrer une gestion de réunions périodiques. Le gestionnaire

80

de cours pourrait alors indiquer qu’une réunion se déroule toutes les semainesà la même heure et ce jusqu’à une certaine date de fin.

Concrètement, cela implique des modifications sur la base de données pourrenseigner la date de fin, mais aussi et surtout une gestion revue pour gérerce type de réunions. C’est-à-dire qu’il faut afficher correctement la page degestion en tenant compte que les réunions du jour peuvent être des réunionsantérieures mais périodiques. Les tableaux de réunions doivent égalementêtre adaptés.

6.5.3 Droits d’accès et intégration avec les groupes

Enfon, pour que l’outil se démarque davantage de l’outil agenda, il fau-drait lui ajouter une gestion des droits d’utilisateurs et même une intégra-tion avec les groupes d’utilisateurs. Les étudiants pourraient s’inscrire à uneréunion ou y inscrire leur groupe. Cela serait en effet intéressant mais de-mande un travail important qui implique des modifications dans la base dedonnées, avec par exemple l’ajout d’une table secondaire MeetingUser pourgérer les utilisateurs d’une réunion.

81

Chapitre 7

Conclusion

Il a été choisi de consacrer un chapitre entier aux différentes décisionsqui ont été prises avant de commencer la production effective de ce mémoire.Il m’est d’avis qu’une bonne évaluation du domaine et des possibilités quisont offertes au développeur, tout comme le fait de définir une bonne archi-tecture avant de commencer une implémentation, permettent de réaliser uneapplication qui se veut maintenable dans le temps et aisément extensible.C’est ainsi que l’ajout de fonctionnalités fut d’une grande simplicité tant lecoeur de l’application avait été pensé avec cet objectif en ligne de mire.

C’est également la stratégie de développement qui a rendu possible l’ex-tensibilité simplifiée de l’outil. En effet, il a été choisi de le découper endifférents modules où chaque module a été développé indépendamment etmême certains parallèlement, et cela par l’unique auteur de ce mémoire.Il est en effet agréable de pouvoir travailler sur différents modules dans lamême journée et il l’est encore plus d’observer comment ces modules misensemble créent une application dont les bugs sont réduits et la maintenancerenforcée.

Le premier module développé a été la gestion de la communication client -serveur, véritable pilier dans ce travail et, il faut le reconnaître, pouvant êtreconsidéré comme la partie centrale de l’outil réalisé. Ce module comprendl’utilitaire alliant Flash et Javascript ayant pour but de permettre l’utilisa-tion d’une nouvelle API du langage HTML5 tout en la rendant accessiblesur des navigateurs actuels et anciens jusqu’à Internet Explorer 6 et ce enne devant ajouter qu’une seule ligne de code HTML et trois fichiers dansson répertoire de travail. Cet utilitaire pourra donc être réutilisé dans biend’autres projets interactifs sur le Web où différentes personnes ont besoind’être connectées ensemble.

82

Ensuite et même parallèlement, c’est le tableau blanc collaboratif qui a étéconçu en tirant partie au maximum des capacités du navigateur. A l’aidedes patrons de conception étudiés dans le séminaire de génie logiciel, il aété possible de développer ce module en utilisant le modèle MVC (Modèle- Vues - Contrôleur). Avec un seul contrôleur en Javascript et deux vuesque sont HTML5 Canvas et Flash, l’accessibilité est garantie pour la quasi-totalité des utilisateurs du Web. Une nouvelle fois, l’architecture logicielle aété pensée pour permettre par exemple l’ajout de nouvelles vues (HTML5SVG, Silverlight, ...) ou l’ajout de nouveaux outils à ce tableau blanc.

Le troisième module a été la gestion de la vidéoconférence pour laquellel’intégration avec les deux précédents modules a été simplifiée. Même sielle nécessite Flash pour fonctionner à l’heure actuelle, de nouvelles APIen HTML5 sont déjà à l’étude et elles devraient pouvoir s’interconnecteraisément à l’outil développé, étant donné que Javascript a été utilisé pourcontrôler la gestion des différents flux vidéos à recevoir et à émettre.

Quant au quatrième et dernier module, il s’agit de l’intégration dans laplateforme Claroline. Là aussi, cela a pu être mené à bien sans trop dedifficultés étant donné la manière dont le logiciel Claroline a été pensé pourrecevoir des outils additionnels et de par le fait que l’application développéepour ce mémoire a été pensée à cet effet, à savoir la facilité à s’intégrer dansun site Internet existant en reprenant son style de présentation.

Cette conclusion se devait de remercier Nicolas Cannasse et tous les contri-buteurs du langage open-source et gratuit HaXe. Celui-ci représente unevraie aide pour le développement d’applications complexes en adoptant unesyntaxe unifiée et une orientation vers différentes plateformes dont Flash,Javascript, Neko VM mais aussi PHP, C++ et bientôt Java.

L’application a été développée en se concentrant davantage sur son archi-tecture et sur ses fonctionnalités principales qui ont été implémentées avecsoin. Le mémoire a ainsi plusieurs fois évoqué un intérêt pour des fonction-nalités additionnelles qui n’ont pas été ajoutées mais qui pourraient l’êtrecar bien souvent, cela a été prévu.

Il convient aussi de dire que de nombreux tests ont été menés sur des caslimites et en situation réelle. Ceux-ci n’ont pas été détaillés dans ce mémoirecar le choix a été de présenter de manière complète l’outil développé ainsique toutes les décisions qui ont dû être prises pour obtenir une applicationaccessible à un maximum d’utilisateur.

83

Enfin, à titre personnel, ce mémoire a été l’occasion d’accroître mes com-pétences dans le développement et plus particulièrement pour le Web, dedécouvrir de multiples outils, langages et machines virtuelles mais aussi biensûr d’utiliser à bon escient les connaissances acquises dans les différents courssuivis à l’Université Catholique de Louvain que ce soit en génie logiciel, enréseau ou encore en bases de données. Ce travail a permis également dedémontrer qu’une architecture logicielle pensée en termes de modules avecl’écriture d’un code propre, commenté, sans duplications multiples et penséen termes d’objets et de fonctions constitue un gain de qualité et est vérita-blement une aide considérable pour la maintenance et l’extensibilité.

84

Bibliographie

[1] Wikipedia (fr + en). http://www.wikipedia.org/.[2] phpwebsocket, php and websockets. http://code.google.com/p/

phpwebsocket/, 2010.[3] Cameron Adams. "html5" versus flash : Animation benchmarking. http:

//themaninblue.com/writing/perspective/2010/03/22/, mars 2010.[4] Alexey Y. Bondar. Websocket actionscript client. http://github.com/

y8/websocket-as, février 2010.[5] Nicolas Cannasse. haxevideo, a flash video server written in haxe. http:

//code.google.com/p/haxevideo/.[6] Jean Carfantan. PHP, MySQL et CSS. Micro Application, 2009. ISBN :

978-2-300-01759-9.[7] Centricle.com. Css filters (css hacks). http://centricle.com/ref/css/

filters/.[8] Claroline. Base de données principale claroline19x. https://docs.google.

com/View?id=ddx5fwz7_89cqt7x6cj.[9] Claroline. Claroline api documentation. http://api.claroline.net/.

[10] Claroline. Manuel du développeur claroline 1.9. https://docs.google.com/View?id=d3vwdgb_40g8rt3tg9.

[11] David Doussot. Intégrerune webcam en flash - php côté serveur.[12] Michael Feichtinger. Html5 websockets example. http://bohuco.net/

blog/2010/07/html5-websockets-example/, 2010.[13] UCL) Frédéric Minne (Institut de pédagogie universitaire

et des multimédias. Zen and the art of claroline mo-dule development. https://docs.google.com/present/view?id=0Aa3YUgLwLABNZDN2d2RnYl81NmQzdzdmcWZ0&hl=en.

[14] Google. Html5 slides. http://slides.html5rocks.com.[15] PHP Group. Php documentation. http://php.net/docs.php.[16] HaXe. Haxe website with api and documentation. http://haxe.org/.[17] Sandeep Malik (IBM). Implement a real-time server push in ajax ap-

plications using socket-based ria technologies. http://www.ibm.com/developerworks/web/library/wa-aj-socket/, septembre 2009.

85

[18] Internet Engineering Task Force (IETF). The websocket protocol(html5). http://www.whatwg.org/specs/web-socket-protocol/, 2010.

[19] Internet Engineering Task Force (IETF). The websocket protocol(html5) : draft 75 versus draft 76. http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-hixie-thewebsocketprotocol-76.txt, 2010.

[20] Makoto Inoue. Living on the edge of the webso-cket protocol. http://blog.new-bamboo.co.uk/2010/6/7/living-on-the-edge-of-the-websocket-protocol, juin 2010.

[21] jQuery. jquery javascript library. http://docs.jquery.com.[22] JSON. Json documentation. http://www.json.org/.[23] Kaazing. Websockets versus comet and ajax. http://www.kaazing.org/

confluence/display/KAAZING/WebSockets+versus+Comet+and+Ajax.[24] Ericsson Labs. What is the websocket difference ? https://labs.ericsson.

com/apis/web-connectivity/blog/what-websocket-difference, mars 2010.[25] Erwan Lefèvre. Position d’un élément (getpos library). http://www.

webbricks.org/bricks/getPos/.[26] Cameron Adams Michaël Chaize. Explorercanvas. http://excanvas.

sourceforge.net/, 2009.[27] Cameron Adams Michaël Chaize. Comparison of performance of flash

player 10.1 and html 5 on mobile devices (video). http://vimeo.com/10553088, mars 2010.

[28] Mozilla. Tutoriel canvas. https://developer.mozilla.org/fr/Tutoriel_canvas, juin 2008.

[29] Mihai Sucan (Opera). Creating an html 5 canvas painting application.http://dev.opera.com/articles/view/html5-canvas-painting/, mars 2009.

[30] Alessandro Pignotti. An efficient actionscript 3.0 just-in-time compilerimplementation. http://lightspark.sourceforge.net/lightspark-thesys.pdf,2009. Mémoire réalisé à l’université Universita degli Studi di Pisa,Facolta di Ingegneria.

[31] Mark Pilgrim. HTML5 : Up and Running. O’Reilly Media, 2010. ISBN :0596806027, URL :http://diveintohtml5.org/ (CC-BY-3.0 License).

[32] Franco Ponticelli and Lee McColl-Sylvester. Professional HaXe andNeko. John Wiley and Sons, 2008. ISBN : 9780470122136.

[33] Adobe Systems. Utilisation de la classe exter-nalinterface. http://help.adobe.com/fr_FR/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7cb2.html.

[34] Adobe Systems. Guide de référence du langage et des composants ac-tionscript 3.0. http://help.adobe.com/fr_FR/AS3LCR/Flash_10.0, 2008.

86

[35] Deneb Meketa (Adobe Systems). Policy file changes in flash player 9and flash player 10. http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html, 2008.

[36] Open Screen Project (Adobe Systems). Real-time messaging protocol(rtmp) specification. http://www.adobe.com/devnet/rtmp/.

[37] Tracy Stampfli (Adobe Systems). Exploring full-screen mode inflash player 9. http://www.adobe.com/devnet/flashplayer/articles/full_screen_mode.html, 2007.

[38] Chromium team (Google). pywebsocket, web socket extension forapache http server. http://code.google.com/p/pywebsocket/, 2010.

[39] World Wide Web Consortium (W3C). Canvas 2d api specification 1.0.http://dev.w3.org/html5/canvas-api/canvas-2d-api.html, 2009.

[40] World Wide Web Consortium (W3C). Html device. http://dev.w3.org/html5/html-device/, 2010.

[41] World Wide Web Consortium (W3C). The websocket api (html5). http://dev.w3.org/html5/websockets/, 2010.

[42] W3Schools. Javascript tutorial. http://www.w3schools.com/js/default.asp.

87

Annexe A

Manuel utilisateur del’utilitaire pour lesWebSockets

Cet utilitaire vous permet de rendre compatible une application Webutilisant la nouvelle API WebSocket du langage HTML5 pour tous les navi-gateurs à partir d’Internet Explorer 6. Vous pouvez reprendre des exemplesde code utilisant cette API ou vous baser sur sa documentation officiellesans avoir à vous soucier des problèmes de compatibilité de cette nouvelletechnologie.

Installation simple

Figure A.1 – Fichiers de l’utilitaire

1. Prenez les trois fichiers composant cet utilitaire et placez-les dans lemême répertoire que votre fichier HTML qui utilise l’API WebSocketHTML5.

2. Insérez la ligne de code suivante dans le haut de la partie <head> dela page HTML utilisant l’API WebSocket (au-dessus de la déclarationde vos scripts Javascript).

<script type="text/javascript" src="WebSocketBridge.js"></script>

88

Remarque Les fichiers WebSocket.js et FlashWebSocket.swf ne serontchargés que si le navigateur de l’utilisateur ne dispose pas de l’API WebSo-cket.

Options

Vous pouvez placer ces fichiers dans un autre dossier que celui utilisé pourvotre fichier HTML utilisant l’API WebSocket. Pour cela, vous devez ajouterle code suivant avant la ligne de code insérant WebSocketBridge.js. Rem-placez PATH et OTHERPATH par les chemins que vous souhaitez utiliserpour votre application.

<script type="text/javascript">var FLASH_WEBSOCKET_PATH = "/PATH/FlashWebSocket.swf";var WEBSOCKET_PATH = "/OTHERPATH/WebSocket.js";</script>

Limitations

– Les WebSockets sécurisés (wss://) ne sont pas utilisables.– Seul le constructeur deWebSocket avec un argument est accepté. L’uti-litaire ne permet donc pas l’utilisation de sous-protocoles.

– Les fonctions utilisables sont : send, close, onopen, onmessage, onerroret onclose. Les variables utilisables sont les quatre constantes CONNEC-TING, OPEN, CLOSING et CLOSED, ainsi que la variable url acces-sible en lecture seule. Toute autre fonction ou variable n’existe paslorsque la version non native est utilisée.

89

Annexe B

Manuel utilisateur de l’outilde réunions en ligne

Voici une capture d’écran de l’outil de réunions en ligne.

Figure B.1 – Capture d’écran de l’interface avec 1 utilisateur

La partie en haut à gauche contient un petit espace de discussion enmode texte. Au centre haut se trouve l’utilisateur principal, un tuteur ou unprofesseur, qui restera toujours à cette place. Les côtés et le haut droit de lapage permettent d’accueillir jusqu’à dix participants. Au centre de la pagese trouve une zone sur laquelle il est possible de dessiner, cela peut être unslide ou une page blanche. Les commandes se trouvent sous cette zone.

90

Remarque L’interface de gestion de réunions sur Claroline est similaireà l’interface des autres modules de la plateforme. Pour ajouter des slides, ilfaut renseigner un nom N dans le formulaire d’ajout ou de modification deréunion. Il faut ensuite déposer chaque slide danshttp://REPERTOIRE_DOCUMENTS/meetings/N/N-i.jpg où i est un numérode slide, démarrant à 0. La taille d’un slide doit être de 600 x 464 pixels.

Notez que le logiciel ImageMagick avec Ghostscript permet de réalisercette opération très simplement en utilisant la commande suivante dans unterminal :convert -quality 95 -resize 600x464! N.pdf N.jpg

Fonctionnement du tableau blanc

L’outil dispose du nombre de slides enregistrés et d’un nombre illimité depages blanches. Que ce soit sur un slide ou une page blanche, il est possiblede dessiner dessus. Le système utilise deux compteurs différents, un pourla série de slides et un autre pour la série de pages blanches. Ainsi, parexemple, au quatrième slide, vous pouvez en un clic revenir à la dixièmepage blanche et dessiner dessus puis en un clic retourner à votre quatrièmeslide pour continuer votre présentation.

L’utilisation du clavier facilite grandement la prise en main de l’outil, voiciles touches que vous pouvez utiliser :

– Flèche haut Changer de mode. Si vous êtes sur un slide, vous bas-culez immédiatement à la dernière page blanche utilisée. Inversement,si vous étiez sur une page blanche, vous revenez alors au dernier slideutilisé.

– Flèche gauche Revenir au slide précédent ou à la page précédente(selon le mode actuellement utilisé)

– Flèche droite Aller au slide suivant ou à la page suivante (selon lemode actuellement utilisé)

– Flèche bas Même comportement que Flèche haut.– Barre d’espace Passer de la sélection de l’outil crayon à l’outilgomme (ou inversement).

Fonctionnement de la vidéoconférence

Cliquez sur Envoyer ma webcam pour diffuser l’image de votre web-cam aux autres participants. Une fenêtre apparaitra avec le choix de votrewebcam. Ensuite, vous devrez cliquer sur le bouton pour autoriser Flash àenvoyer l’image de votre webcam.

91

Vous apparaîtrez alors dans le carré qui vous est attribué dans l’interface.L’image affichée correspond approximativement à ce que les autres utilisa-teurs voient. Il vous est possible de cliquer sur un carré avec une webcampour la voir en plein écran.

Remarque Il est nécessaire pour la personne qui diffuse l’image de sawebcam d’utiliser un casque ou des écouteurs afin que votre micro ne captepas les sons produits par les autres participants. En effet, dû au décalaged’environ 1 seconde, cela créerait un écho désagréable pour tous les partici-pants.

92

Annexe C

Code source

Le code source est accessible en ligne sur le site Google Code qui permetde créer facilement un projet open-source.

L’URL du projet est :http://code.google.com/p/meetingtoolclaroline/

Une version électronique en PDF de ce mémoire est également accessiblesur ce site.

93