Ndr: Pour en savoir plus sur Fréquence Banane, radio du campus lausannois, vous pouvez vous reporter à l'article paru dans le Flash de l'EPFL du 16 janvier 1996.

Les développements que nous avons décidés d'entreprendre pour le serveur banane résultaient du constat suivant:

• les membres de la radio qui n'étaient pas des informaticiens, ne participaient absolument pas à la réalisation du serveur;
• les pauvres informaticiens de l'association n'arrivaient absolument pas à suivre les production de la radio pour les mettre sur le serveur et, surtout, ne savaient pas du tout comment retranscrire les activités en documents HTML.

Rappelons ici que la moitié des membres de l'association poursuivent des études à l'UNIL et n'ont aucune raison de connaître l'informatique, qui plus est les incantations sataniques d'UNIX! Le résultat en a été une prolifération anarchique de notre serveur qui devenait de jour en jour plus difficile à maintenir.

La situation peut être schématisée de la façon suivante:

Evidemment nous avons tenté de former les gens "normaux" pour qu'ils participent à la réalisation du serveur:

Cette solution a immédiatement connu un franc insuccès! Après quelques cogitations supplémentaires nous avons choisi la solution suivante (il n'y a pas de question stupide, seules les réponses le sont):

La solution

Un premier test de l'interfaçage de requêtes SQL sur la base de données a été fait avec une base simple à une seule table: la Bédéthèque de Satellite:

Il fallait d'abord mettre au point un système d'identification pour cette partie du serveur afin d'en contrôler l'accès. C'est désormais chose faite, puis que les membres de Fréquence Banane peuvent facilement, suivant les accès qui leur ont été attribués, transférer des fichiers FilemakerPro, mettre à jour leurs données personnelles, créer une page de présenta tion à partir d'une forme html, et finalement lire leurs mails dans une interface cohérente et (plus ou moins) facile.

Le contrôle d'accès n'est pas d'une sécurité absolue. Le principe repose sur la génération d'une clé temporaire pour le temps de la session. L'utilisateur entre une fois son mot de passe d'utilisateur UNIX sur la station (même niveau de sécurité que telnet). Par la suite la clé temporaire se trouve dans tous les liens qu'il suit au sein de cette partie du serveur, mais n'est plus valable une fois la session terminée.

Ainsi, vous avez peut-être déjà eu l'occasion de voir les pages de présentation et de contact qui ont toutes été générées automatiquement et qui sont accessibles depuis l'ancien serveur.

Par contre, pour ce qui est de la mise en base de donnée des sons produits par la radio, un projet de semestre est en cours, en collaboration avec le laboratoire de télécom. Le principe est le suivant:

• des étiquettes sonores codées sont intégrées aux modules de production;
• la station écoute en permanence et lorsqu'une de ces étiquette est détectée, elle stocke le module reconnu directement dans la base de données avec les informations essentielles.

On obtiendra ainsi une automatisation plus ou moins complète de la mise sur le serveur des émissions de Fréquence Banane sans aucune intervention.

• Chaque demande de document fait l'objet d'un traitement par un script qui recompose celui-ci à partir de la base. C'est la solution qui a été adoptée pour le serveur Couleur3 notamment. Elle présente l'avantage d'une gestion facile de la cohérence, des mises à jour aisées la plupart du temps. Par contre, certaines modifications entraî nent un lourd remaniement des outils d'accès à la base; la structure arborescente pourtant avantageuse dans les serveurs WWW est difficile à réaliser; la présentation est très uniforme et répétitive. De plus, les performances peuvent se dégrader pas sablement si le serveur devient complexe.
• Une autre solution consiste, à l'opposé, à figer toutes les requêtes possibles dans des fichiers html standards, et utiliser des éléments qui ne sont pas tous dans la base de données. Un tel outil a été mis au point à Fréquence Banane. Il s'agit d'une sorte d'interpréteur, qui, à partir d'un fichier de défini tion des éléments constitutifs, génère les docu ments. Le fichier de définition est d'une syntaxe relativement (!) aisée et offre une très grande flexibilité qui se paye en performance, rendant donc impossible la génération des documents sur requête. La version actuelle qui fonctionne (plus ou moins!) met à peu près une heure pour générer une dizaine de documents. Elle nécessite donc d'être encore améliorée et se trouve toujours sur le billard.

Enfin, la nouvelle version de Netscape et les nouveaux tags qu'elle apporte, notamment les frames , permet de mélanger les différentes façons de traiter les requêtes. On peut ainsi avoir des documents générés dynamiquement et d'autre stockés statiquement. Ceci permet de mettre au point tout un environnement petit à petit, et donc, à l'heure actuelle de déjà présenter une partie du serveur: