Réalisé par : Laurent Wozniak et Pierre Jourdan ( wozniak@essi.fr, jourdan@essi.fr )
L'archive de la libraire cgic utilisée : cgic103.tar.gz.
Une archive se trouve sur le lien suivant : demoManager.tar.gz (64Ko).
L'archive suivante est identique mais contient déjà une petite gallerie de démonstrations : demoManager_demo.tar.gz (105Ko).
Cette archive contient les répertoires de notre logiciel, les executables SunOs et nos fichiers sources. Il faut la décompresser et laisser ou placer l'exécutable cgi dans un répertoire accessible par le serveur HTTP et qui sera en outre autorisé à lancer des cgi ( pour nous l'exécutable cgi-bin/demoManager.cgi ). Vous pouvez être amené à configurer votre serveur HTTP pour cela.
Il faut placer les répertoires : html, place et cgi-bin au même niveau. Le répertoire place doit autoriser le propriétaire du serveur HTTP (généralement nommé "nobody") à écrire dans le répertoire place. Cela pour permettre au programme d'archiver les démonstrations dans ce répertoire et d'être sûr de les retrouver longtemps aprés le départ de l'école de leurs auteurs.
Il est conseillé si vous recompiler le programme de réaliser un lien symbolique depuis le repertoire cgi-bin vers l'executable créé dans le repertoire sources.
La page d'accueil offre le choix entre ces trois options :
Cette option permet de tester la redirection du display avec un exécutable afin de s'assurer que cela fonctionne. Chaque étudiant devrait d'abord lancer son exécutable une fois de cette manière avant de procéder à l'installation de sa démo dans demoManager. Ceci afin d'éviter les démonstrations douteuses et de faciliter la vie à son "professeur adoré".
La page de lancement est sobrement constituée de seulement deux champs : un pour le path du programme à executer et l'autre pour fixer le display. Si le display ou les droits d'accés sont mal positionnés, on recharge la même page avec ces indications.
Photo d'écran de la page de test :
Cette option renvoie à une page html qui sert de formulaire à l'étudiant pour rentrer les informations relatives à sa démonstration. Ces informations seront affichées dans la la page de garde de celle-ci. L'utilisateur doit obligatoirement entrer les champs concernant le nom de la démo, les auteurs et les paths d'accés. Ceci est vérifié par une fonction JavaScript. On peut en outre renseigner sur les langages utilisés, fournir des commentaires sur son projet, ainsi qu'une photo décran de son éxecution, etc...
Pour rentrer le chemin d'accés à son répertoire, l'utilisateur doit utiliser par précaution le boutton "Browse", situé à droite du champ, qui lui permet de choisir via une boite de dialogue le path complet de son répertoire.
Il doit ensuite rentrer le path d'accés à l'exécutable, situé sous la racine du repertoire cité ci-dessus, en procédant de la même façon.
La gallerie est une page html statique qui renvoie aux pages de garde des démonstrations déjà installées. Elle affiche brièvement le titre et la description des démos et fournit pour chacun un boutton de lancement sur leur page de garde respective.
Un boutton de regénération de la page gallerie situé en bas de page, permet de recréer cette page en fonction des repertoires de démonstrations restant comme archives. Cela permet au professeur (propriétaire des repertoires d'archives) de "faire le ménage" dans ce
Photo d'écran de la gallerie :
Une fois sur la page de garde d'une démonstration, l'utilisateur voit les descriptions rentrées lors de l'installation et peut lancer la démo en donnant des arguments à l'executable et, là encore, en redirigeant le display vers son poste de travail.
Photo d'écran d'une page de garde :
Remarque:
Le repertoire place qui se remplit au fur et à mesure de l'installation des démos est la propriété du user du serveur HTTP. Cela implique que si ce repertoire et chez soi, on peut être surpris de ne pas pouvoir effacer des fichiers dans ce repertoire. Seul le cgi ( ou le propriétaire du server HTTP) peut nettoyer ces fichiers du répertoire: Nous fournissons donc une petit cgi cgi-bin/clean.cgi (situé dans le répertoire cgi-bin).
Un répertoire ( situé à l'adresse suivante : /u/dessi3/wozniak/DemoSar6 ) contient des répertoires prêt à être archivés. Et La page d'accueil vous attend.
Nous avons choisi d'utiliser la librairie cgic, car n'ayant pas le temps d'appréhender le langage java, nous souhaitions utiliser un langage performant pour l'éxecution des scripts cgi. Or la seule librairie c que l'on nous a montré est cgic. De plus, une applet java normale (c'est-à-dire pas sécurisée et authentifiée ) n'a pas accès aux fichiers des utilisateurs et n'avait donc pas l'air adapté au sujet. Le choix de Pearl a été lui-aussi évincé à cause de sa lenteur d'execution et le fait que ce projet ne devait pas nécessiter les avantages de ce langage interprété.
Le logiciel est construit sur les quelques répertoires suivant : place, html, cgi-bin et sources.
Pour éviter la surpopulation de cgis et pour permettre au server de charger une seule fois en mémoire l'éxecutable, nous avons choisi de réaliser un unique cgi. Nous demandons donc à notre cgi d'accéder à tel ou telle application via un paramètre. Cela permet aussi une meilleur lisibilité du programme, les fonctionnalités étant regroupées au même endroit.
Afin de mettre le moins d'html possible dans notre code, nous avons optés pour créer des pages htmls qui nous servent de calques pour l'affichage des pages par l'executable cgi. Ce procédé est maintenant courant. Cela offre l'avantage de pouvoir changer la forme des pages sans avoir à recompiler notre programme. Ces pages contiennent donc des tags de commentaires qui nous servent de "flags" d'indications et permet d'insérer aux endroits stratégiques les informations manquantes.
Les fichiers et les pages Htmls que nous avons écrit sont sobres (dans l'esprit d'Arnaud LeHors), d'abord parce que le but du projet ne consistait pas à faire de "belles pages à la mode et pleines de fioritures" et ensuite parcequ'elles pourront être mises en forme plus tard avec des stylessheets .
L'ouverture du display en c ne permet pas la récupération des erreurs directement. En effet, le protocole d'affichage des erreurs dépend de l'implémentation du serveur X-Window. Nous avons donc choisi de rediriger les erreurs directement dans nos pages en les formattant indirectement au format html. Cela permet par exemple d'avoir les messages du serveur X directement dans nos pages, les erreurs affichées en rouge étant mises en évidence .
Deux erreurs peuvent se produire : soit le display n'existe pas, soit le serveur HTTP executant notre cgi n'est pas autorisé à se connecter au display ( par le serveur X-Window ) à se connecter. Dans ce dernier cas, l'utilisateur doit rajouter le serveur HTTP à se connecter via un xhost + xxxx sous Unix.
Une troisième erreur est
Pour donner par défaut le display du navigateur, on récupére la variable cgi d'environnement "REMOTE_HOST" que l'on peut supposer être du même nom que le display de l'utilisateur. Si celui-ci passe par un proxy ou a une installation bizarre de son navigateur, il doit obligatoirement préciser le champ display.
Une fois la démonstration lancée, la page html de lancement attend la réponse, c'est-à-dire la fin de l'execution de la démonstration. Cela peut entrainer une coupure de la liaison par le navigateur, si la démonstration dure longtemps. Mais nous avons tenu à ce que cette attente soit réalisée et que le démo ne soit pas lançée puis séparée du processus cgi pour les raisons suivantes : Si nous avions fait cela, nous n'aurions plus accès à ce processus. : Il aurait alors fallu donner la possibilité à l'utilisateur de tuer le processus en question, mais cela ne pouvait se faire sans faillir à la securité du serveur. Cela risquait d'entrainer des processus orphelins continuant à s'executer sans que personnne ne les voit. Actuellement si l'utilisateur coupe la connexion HTTP ( en cliquant sur les bouttons Stop ou Back de son navigateur, le serveur HTTP peut tuer le processus cgi lancé (mais cela dépend des choix du serveur, cela n'ait pas possible pour les cgi shells).
Cette solution a évoluée pendant la réalisation du projet :
Il nous a été demandé au départ de ne pas réaliser de base de données. La difficulté du sujet résidait justement dans le fait qu'il fallait essayer le plus possible de stocker les données de manière statique dans des pages htmls. Cela limite forcément les possiblités de celles-ci. Il est en effet difficile d'accéder aux informations d'une démonstration une fois la page de celle-ci générée. Bien que ceci aurait été possible, là encore via des tags contenant des informations de manière codée, cette solution ne présente aucun intérêt. On ne peut en effet pas vouloir à la fois les possibilités d'une base de données et avoir des pages pratiquement statiques, cela serait vraiment trop lourd.
La regénération de la gallerie est un bel exemple du principe de modification des informations malgrès l'handicap des pages statiques. La question était : "Comment retrouver l'information stockée dans la gallerie, aprés avoir effacer celle-ci ?". Pour résoudre élégamment cette question, nous stockons "directement" dans un fichier auxiliaire (vraiment tel quel) les insertions que nous faisons, lors du rajout à la page "gallerie.html" des informations de la démonstration en cours d'installation, à raison d'un fichier par répertoire de démo. Il ne reste alors plus qu'à concaténer tous ces fichiers et à rajouter d'un bloc à la page gallerie vierge ces informations. Une gallerie des démonstrations restantes est alors facilement recrée !
L'application gagnerait à être quelque peu amélioré avec peu de choses, car même si ces choses ne sont pas trés difficile, nous n'avons pas eu le temps matériel de les réaliser. Il faudrait pouvoir gérer un plus grand nombre de démonstrations. Pour cela, il faudrait rajouter la possibilité de définir des variables d'environnement lors de l'installation d'une démo. Il faudrait donner le choix entre trois type d'archives :
En vous remerciant d'avoir tout lu,
Laurent Wozniak et Pierre Jourdan