VeHO

Plateforme de distribution de contenu

Du mot latin “veho” signifiant “transporter”.

Présentation du problème

Il est de plus en plus difficile pour des développeurs indépendants ou de petites entreprises de faire connaître leurs produits et de pouvoir distribuer leur contenu de façon abordable. La bande passante étant de plus en plus disponible et abordable, il est logique de changer de la distribution en boîte à la distribution par support numérique.

Des solutions de distribution d’applications via téléchargement existent déjà :

  • Steam1 par Valve
  • Impulse2 par Stardock
  • GOG.com3

Les deux premières solutions offrent une application permettant d’accéder aux applications que vous avez achetées sur leur plateforme respective. Dans le cas de Steam, un aspect communautaire est relativement présent. Vous pouvez voir les applications que vos amis achètent et les évènements auxquels ils participent. Les forums sont dissociés de l’application, mais sont quand même disponibles et accessible via un fureteur Web.

Dans le cas de Impulse, les fonctionnalités à caractères sociales commencent à apparaître, mais sont tout de même limités. Il y a, à l’instar de Steam, la possibilité de communiquer avec ses amis via messagerie instantanée, mais c’est tout pour l’instant.

Puis, GOG.com n’est qu’un site Web où on peut acheter de vieux jeux et où les communautés déjà existantes se retrouvent après plusieurs années. Les forums sont très utilisés et la communauté semble très vivante. Les commentaires positifs de certains utilisateurs en poussent certainement d’autres à acheter des produits qu’ils ne connaissent pas, puisqu’ils leur ont été recommandés.

Présentation du projet

Le but de VeHO est d’offrir une plateforme complète de vente en ligne dont l’aspect communautaire a été intégré directement. Le site Web mise sur l’aspect communautaire afin que les clients puissent échanger leurs commentaires et aussi créer des groupes de personnes ayant les mêmes intérêts afin de stimuler les échanges et les ventes.

L’application client, quant à elle, permet d’interagir sur le site, comme à l’aide d’un fureteur, mais aussi de télécharger tout le contenu, pas seulement limité aux applications ni aux jeux, acheté via celle-ci. De plus, toute la plateforme est libre de droits et peut-être modifiée par quiconque le désire afin de pouvoir répondre à ses propres besoins.

Toutes les technologies ont été choisies particulièrement parce qu’elles sont ouvertes et libres de droits (opensource). Ceci est très important parce qu’il permet à tous ceux et celles désirant essayer VeHO de pouvoir le faire sur un plus grand nombre de plateformes.

Répartition des tâches

Nous n’étions que deux étudiants à travailler sur ce projet. Les tâches ont donc été réparties très simplement : un s’occupe de l’aspect client, l’autre de l’aspect serveur.

Maxime Dupuis a été chargé de s’occuper du client et de coordonner les efforts de l’équipe avec que tout se déroule bien. Il s’est occupé aussi des communications entre le client et le serveur de messagerie.

Maxime Carey, quant à lui, s’est occupé du serveur applicatif et du serveur de messagerie. Le but étant d’intégrer les deux de sorte que le client ne communique qu’avec le serveur de messagerie.

Architecture

La plateforme VeHO se décompose en trois parties. D’abord, il y a le serveur applicatif qui gère toutes transactions ainsi que l’aspect communautaire. Ensuite, le serveur de messagerie qui fait le lien entre le serveur applicatif. Puis, le client ainsi qu’entre deux clients et le client qui sert de pont de téléchargement et d’outil de communication entre les autres clients et le serveur applicatif.
Architecture de la plateforme VeHO

Serveur applicatif

Le serveur applicatif est le point central de la plateforme VeHO. Sans lui, le client ne se résume qu’à un simple client de messagerie instantanée. Il héberge aussi plusieurs fonctionnalités comme la boutique en ligne, les usagers et les communications entre eux. Il se doit donc d’être flexible et extensible.

Comme l’aspect communautaire était une priorité, nous avons préféré choisir un CMS (Content Management System ou système de gestion de contenu) plutôt qu’une application de commerce en ligne (eCommerce). Le CMS choisi est Drupal4 dans sa version 6 puisqu’il est facilement extensible, est reconnu pour sa flexibilité et sa performance, il est écrit en PHP5 et utilise une base de données MySQL6 pour sauvegarder les données. Drupal peut donc être installé sur plusieurs plateformes différentes. De plus, il existe plusieurs modules ajoutant plusieurs des fonctionalités désirées.

En plus du système de facturation classique, la boutique en ligne devait être capable de supporter plusieurs vendeurs. Nous avons utilisé Übercart7 qui offre déjà le support pour plusieurs vendeurs, mais aussi plusieurs catalogues, un panier d’achat et un système de facturation. La seule chose que Übercart ne supporte pas est de communiquer avec lui par services Web, qui sont offerts grâce à un autre module Drupal. Il faut mentionner qu’on ne voulait pas que les utilisateurs puissent télécharger leurs achats directement à partir du site Web, mais plutôt à partir du client.

L’aspect communautaire a été simple à mettre en place. Nous avons choisi d’installer des forums sur le site afin de permettre des échanges sur divers sujets comme les vendeurs, leurs produits, etc. Les clients ont également la possibilité de créer des groupes particuliers auxquels d’autres peuvent s’inscrire. Ces groupes forment alors un lieu commun d’échange sur un sujet en particulier. Par exemple, un adolescent pourrait créer un groupe sur les jeunes de 12 à 17 ans jouant à des jeux vidéo uniquement sur un type de console. De cette façon, on crée un lien d’appartenance entre plusieurs utilisateurs ce qui les encouragent à revenir et à participer.

Finalement, nous avons cru bon d’instaurer un aspect un peu plus personnel, car on ne désire pas toujours participer à des conversations. Dans le cas où l’on souhaiterait écrire notre opinion sur un sujet, chaque utilisateur peut écrire sur son blogue. Les articles peuvent être lus et commentés par les autres. Chaque personne a également un profil personnalisé et une liste de contacts qui lui sont propres.

Serveur de messagerie

Le serveur de messagerie sert de pont entre le serveur applicatif (le site Web) et le client. C’est par lui que véhicule toutes les informations concernant un utilisateur et ses amis. Le protocole de communication choisi pour réaliser la tâche est Extensible Messaging and Presence Protocol ou XMPP8. Il a été choisi parce que le standard est ouvert, qu’il est facilement extensible et parce qu’il a été rigoureusement testé depuis son acceptation comme standard par l’IETF en 2002.

Le protocole XMPP est dit fédéré puisque chaque serveur est configuré pour pouvoir communiquer avec les autres serveurs XMPP existants. Ce qui implique que si je me crée mon propre serveur, je peux communiquer avec n’importe quel utilisateur connecté aux serveurs de Google (plus précisément gmail) par exemple. Bien sûr, il est possible de pouvoir interdire de telles communications de serveur à serveur.

Plusieurs serveurs XMPP existent. Nous avons d’abord considéré eJabberd qui est très connu dans le milieu puisqu’il est facile d’augmenter le nombre de noeuds (ou serveurs). Par contre, sa configuration est difficile et la documentation à son sujet presque inexistante. C’est pourquoi nous avons finalement opté pour Prosody9 qui, lui, est écrit en Lua, est plus récent et facilement configurable.

Le but ultime serait de faire transiger toutes les communications entre le serveur applicatif et le client par le biais du serveur de messagerie. Malheureusement, faute de temps, nous avons dû nous limiter aux communications par messagerie instantanée.

Ne plus avoir à utilser de services Web aurait d’énormes avantages :

  • L’adoption du protocole à grande échelle permettrait aux acheteurs de se connecter à un seul serveur et avoir accès à des produits provenant d’autres sites;
  • Toutes communications avec le serveur applicatif seraient sécurisées puisque XMPP suggère fortement d’utiliser SSL;
  • Il ne suffirait que d’implémenter le protocole étendu afin d’obtenir un autre client pour une autre plateforme, ne supportant ni Python ni Qt4 par exemple;
  • Puisque XMPP fonctionne en mode connecté, chaque évènement peut être traité presque instantanément chez le client.

Parce que le client utilise les services Web de Drupal ainsi que le serveur de messagerie, il y a dédoublement de l’information. Les informations concernant les comptes, soient noms d’utilisateurs et mots de passe, ainsi que les listes de contacts doivent exister sur les deux serveurs en même temps. Il faut donc s’assurer de leur intégrité. À petite échelle, ceci est faisable, mais à grande échelle, c’est impensable si on veut offrir un service en temps réel.

Client

Le client sert de pont entre l’acheteur et le serveur applicatif. Il permet aux utilisateurs de contribuer du contenu sur le site, avec ses amis, et également de télécharger le contenu qu’il a acheté.

Le L’architecture du client est relativement simple. Pour l’interface graphique, on utilise Qt410 qui est appelée à partir de Python11 à l’aide de la librairie PyQt412 qui communique, elle, directement avec Qt4. On ne peut appeler la librairie directement puisqu’elle est écrite en C++. C’est pourquoi on a besoin de l’intermédiaire. Le langage Python et Qt4 ont été choisis parce que ces technologies sont supportées sur plusieurs systèmes d’exploitation. De plus, Python est un excellent langage de prototypage. Le développement s’effectue rapidement et on peut corriger le tir très facilement.

Le graphique suivant montre globalement l’architecture du client.
Architecture client VeHO

En bleu, nous avons les classes produites au cours du projet, en jaune, les librairies utilisées et en rouge, les classes générée à partir de l’éditeur de fenêtre QtDesigner. Il est évident que le code généré utilise des éléments de la librairie Qt4.

La partie la plus intéressante du client reste le client XMPP. Un pont entre la librairie XmppPy (plus précisément la classe xmppClient) et Qt4 a été créé afin de facilité la gestion des évènements. Ainsi, à chaque fois qu’on reçoit un message du serveur XMPP, il est transformé en signal Qt4 approprié. Par exemple, lorsqu’un ami se connecte au serveur de messagerie, la fenêtre de chat principale crée une nouvelle instance de QXmppUser qui sera un peu plus tard reliée à une instance de QChatWidget. Cette dernière se chargera d’afficher et d’envoyer les messages entre l’utilisateur et son ami.

Présentement, le client est dispensable. Il suffierait d’implémenter le protocole XMPP au sein des pages Web afin d’en éliminer le besoin. Par contre, en faisant celà, on perd beaucoup côté expérience utilisateur. Les navigateurs Web ne sont pas aussi sensible et rapide face aux délais et sont encore moins rapides que les applications Internet. De plus, même s’il est possible, il est très difficile de pouvoir faire fonctionner un site Web lorsque l’utilisateur n’est pas connecté à Internet.

Expériences personnelles

Effectuer un projet en recherche et développement demande énormément d’investissement et les défis sont nombreux. VeHO était en quelque sorte une preuve de concept qui s’est avéré fructueuse. Cependant, nous avons dû apprendre beaucoup de nouvelles technologies avant de pouvoir travailler avec elles de façon efficace. De plus, avant de faire le bon choix, nous en avons essayé plusieurs autres, ce qui nous a fait perdre considérablement du temps de développement. Le travail par essais-erreurs fait en sorte que l’estimation du temps que prendra une tâche est presque impossible au tout début.

Comme nous étions limités en temps, nous n’avons pas pu apprendre complètement les outils avec lesquels nous travaillions. Avec nos connaissances limités, nous n’avons probablement pas développé de la façon la plus efficace possible. Par contre, en connaissant de mieux en mieux ces outils, nous sommes en mesure de mieux estimer les tâches que nous avons à effectuer et à mieux diviser ces tâches.

Nous étions également limité en frais de matériel. Un serveur nous a été prêté par le département d’informatique et nous devions faire avec. Cela causait problème lorsque nous voulions travailler depuis l’extérieur du campus principal, certains ports n’étant pas ouverts à la communication. Donc, lorsque nous voulions travailler à l’extérieur, nous devions répliquer la configuration du serveur sur un de nos ordinateurs.

Conclusion

En conclusion, un projet en recherche et développement demande beaucoup d’investissement de la part de tous les membres de l’équipe. L’estimation est difficile en terrain inconnu et les phases de prototypage peuvent être fastidieuses et frustrantes lorsqu’on voit son travail rejeté suite à un travail de longue haleine.

Par contre, le fait de s’être servi de projets et protocoles ouverts comme base de développement a grandement accéléré le processus de développement une fois les technologies chiosies. Il suffit de prendre le temps qu’il faut et choisir ce qui convient le mieux à la tâche qu’on a à accomplir.

Notes