* TODO Refactorer le code gérant la conversion en JSON des objets Scala
- Voir question de la semaine du <2015-02-09 lun.> au <2015-02-13 ven.>
* TODO Mettre en place un outil de concaténation et de minification du JS
- Plutôt que de charger plusieurs fichiers JS, il serait préférable
  que le client ne charge qu'un seul fichier contenant tout le code JS
  nécessaire à l'application.
- Ceci permettrait d'améliorer les performances de l'application en
  réduisant le temps de chargement de la page (1 seule requête HTTP
  pour le JS au lieu de... beaucoup).
- Minifier le code de ce fichier permettrait d'améliorer encore plus
  la vitesse de chargement de la page.
- Voir du côté de [[http://gruntjs.com/][Grunt]]. 
* TODO Automatiser les tests du JS
- Il faudrait que les tests JS s'exécutent de façon automatique.
- Les tests pourraient se lancer à la suite de la tâche de concaténation et de minification du code JS.
- Voir si un plug-in *Grunt* existe pour *jasmine*.
* TODO Interrompre l'exécution du programme si une exception est levée
- Le programme devrait s'interrompre lorsqu'une exception est levée,
  par exemple lorsqu'on essaie de poser un baggle sans en avoir un.
* TODO Créer un mode d'auto-complétion pour BuggleWorld
* TODO Fixer le bug du baggle ne s'affichant pas
   - Lorsque webPLM a été testé sur le Mac de Gérald, le baggle
     présent normalement dans l'exercice n'était pas affiché.
   - Reste à voir si ce bug est reproductible.
* TODO Lancer la démo lorsqu'on bascule sur le monde objectif pour la 1ère fois
* TODO Limiter la vitesse d'exécution du programme du client
   - Si l'utilisateur boucle indéfinitivement sur une ou des méthodes
     ne comportant pas de stepUI, tel que System.out.println, alors
     son programme surcharge le serveur empêchant l'utilisateur de
     le stopper autrement qu'en arrêtant manuellement le serveur.
   - Lancer le programme de l'utilisateur dans une autre JVM
     permettrait de mieux contrôler son exécution et de corriger ce
     problème.
* TODO Modifier les messages concernant l'envoi de données au serveur
   - Actuellement, plusieurs messages sont affichés pour informer
     l'utilisateur que PLM est en train d'envoyer les données de son
     activité au serveur.
   - Ces messages apparaissent même si l'utilisateur a refusé de
     communiquer ses données, ce qui peut prêter à confusion.
   SCHEDULED: <2014-12-08 lun.>
* TODO Indiquer à l'utilisateur si la connexion avec le serveur a été perdue
   - Rien n'indique actuellement à l'utilisateur que la communication
     avec le serveur a été interrompue, ce qui peut être confus.
* TODO Mettre en place un processus de reconnexion de la websocket
   - Si le serveur rencontre un problème momentané, le client doit
     être le moins possible impacté.
   - Une tentative de reconnexion de la websocket à intervals
     réguliers permettrait d'éviter à l'utilisateur de recharger la
     page et (surtout) perdre ses dernières modifications.
* TODO Vérifier le bon fonctionnement de Git côté serveur
   - PLM affiche le message suivant au démarrage du serveur:
     "Impossible de récupérer une session adéquate sur les
     serveurs...".
* TODO Retirer la partie UI présente dans PLM-library
* TODO Permettre à un utilisateur de gérer les vues des mondes dynamiquement
   - Actuellement, seul le monde selectionné est
     affiché. L'utilisateur doit donc changer de monde selectionné
     pour observer l'exécution du programme sur un autre monde.
   - Donner les moyens à l'utilisateur d'ajouter ou de retirer
     dynamiquement les vues des mondes permettrait à chacun de
     personnaliser son interface.
* TODO Se renseigner sur seccomp-bpf
   - Permettrait de sandboxer les programmes utilisateurs, à voir
     comment ça s'utilise et cela fonctionne.
* TODO Se renseigner sur Docker
   - A première vue, ça pourrait être utile pour exécuter le code des
     clients une fois passé en mode serveur centralisé.

