ZEP-28 : Médiathèque

Cette ZEP est la formalisation de la discussion entamée ici qui visait à permettre l'ajout de « pièces jointes » dans les tutos et messages de forum. Après discussion, il a semblé plus opportun de simplement élargir le fonctionnement des galeries d'images à d'autres types de documents.

Pour ceux qui connaissent, les blogs DotClear ont un outil appelé « Médiathèque » qui permet de faire exactement cela : outre que je trouve le nom tout à fait adapté, l'outil est efficace, et c'est lui que j'ai à l'esprit en rédigeant cette ZEP.

Partir de l'acquis

L'idée n'est pas de coder de novo un outil médiathèque mais de partir de la base des galeries d'images et d'étendre son fonctionnement. Fondamentalement, pour que la médiathèque fonctionne sans fioritures mais surtout sans causer de tort à ZdS, il faut respecter deux conditions : n'autoriser que certains types de fichiers à être hébergés sur le site, et imposer une limite de taille pour les fichiers hébergés. À quelques ajustements près, on peut largement réutiliser le fonctionnement existant.

Formats de fichiers autorisés

J'ignore comment se fait actuellement la vérification de format des images. Si l'outil utilisé est un outil généraliste qui ne se fonde pas sur les extensions, du genre de la commande file des systèmes Unix, alors tout va bien, on part là-dessus. S'il s'agit d'un outil maison dédié spécifiquement aux images, ou qui se base sur les extensions, il faudra bien sûr en changer. file, c'est bon, mangez-en.

En première approximation, les formats suivants devraient être autorisés.

• Tous les principaux formats d'image, même ceux qui ne peuvent être affichés directement sur le site : JPEG, GIF, PNG, TIFF, BMP, XCF, PSD.
• Les principaux formats de modèle 3D, pour les cours de graphisme.
• Les fichiers plein texte, qui ne peuvent pas causer de tort, et qui regroupent notamment :
  • les longs codes source, que l'on ne sera plus obligé de mettre dans des cadres « secret » ;
  • les fichiers RTF, et de manière générale tous les formats de type markdown ou ReST ;
  • les pages Web entières, en HTML+CSS+JS ;
  • toutes les diverses saveurs de XML, qu'il s'agisse d'images SVG, de formules en MathML ou de descriptions archivistiques en EAD ;
  • les documents LaTeX avant compilation ;
  • etc.
• Les PDF, au minimum pour permettre d'offrir dans le tuto un lien vers une version PDF retravaillée à la main plutôt que l'export automatique.
• Dans le même état d'esprit, même si cela devrait servir moins souvent, les DjVU.
• Les fichiers bureautiques de MS Office avant le passage au OOXML (les .doc, .xls, .ppt, etc.).
• Les archives ZIP (qui peuvent être facilement ouvertes en Python), à condition qu'elles ne contiennent que des fichiers eux-mêmes autorisés. De cette manière, on permet l'import de fichiers en OpenDocument, en OOXML (les .docx, etc.) et en ePub, du moment qu'ils n'ont pas été trafiqués pour rajouter des fichiers dans l'archive. Ce système permettra également de fournir des codes sources complets en plusieurs fichiers ou de très gros fichiers textes (par exemple, un dictionnaire sur lequel tester un programme).
• Enfin, pour ne pas poser de problème avec les fichiers de bureautique et les ePub, il faut également autoriser les fichiers de police de caractère.

La question est en suspens pour les vidéos. De manière générale, pour qu'une vidéo soit d'une qualité suffisante et assez longue pour présenter un intérêt, elle doit peser plusieurs dizaines voire plusieurs centaines de mégaoctets, et ZdS ne peut pas se permettre de supporter cette charge. Cependant, certaines technologies récentes comme le WebM ou le GIFV permettra d'obtenir des animations de grand qualité dans une taille similaire à un simple GIF. Du coup, ça peut valoir la peine quand même.

Certains formats ne seront jamais acceptés, essentiellement pour des raisons de sécurité.

• Les fichiers objet, codes sources compilés, applets Java et toutes formes d'exécutables, notamment les archives auto-extractibles.
• Les fichiers Flash.

Taille des fichiers

Là encore, il y a déjà un système qui vérifie la taille des fichiers et refuse les fichiers qui pèsent plus de 1024 Ko. Il est évident qu'on va le réutiliser pour la médiathèque. Cependant, cette limite de taille peut poser quelques problèmes avec les nouveaux formats de fichiers. Prenons un exemple simple, qui a toutes les chances de se produire. Mon récent cours d'histoire des sciences compte un certain nombre d'images, qui totalisent 2,2 Mo. Même en les réduisant de taille, ce que je peux me permettre avec une mise en page plus souple que sur ZdS, je reste au-dessus de la limite du Mébioctet. Tout ça pour dire que si je fais une version PDF de mon cours, il est tout à fait impossible qu'il fasse moins de 1024 Ko. Donc, je suis d'avis qu'il faudrait rehausser la limite maximale de taille pour certains formats de fichiers.

Ce qui doit changer

Malgré tout, il n'est pas possible de tout conserver tel que c'est actuellement. À commencer par l'interface, qui est conçue spécifiquement pour des images : ainsi, la génération de miniatures, ainsi que les codes générés automatiquement pour inclure l'image dans le markdown, n'ont pas de raison d'être pour un PDF ou un code source C. D'autres informations pourraient être affichées à la place, comme les métadonnées extraites d'un PDF (pour vérifier que l'on ne laisse pas filtrer n'importe quoi sur un site public), mais ce n'est pas absolument nécessaire.

Ensuite, quand une image est importée, son nom est changé en un code d'identification dénué de signification. Autant pour une image qui n'a pas vocation à être visionnée en tant que telle mais incluse dans une page Web, ce n'est pas gênant. Autant, en revanche, c'est un peu dérangeant que la version PDF propre et jolie de mon tuto s'appelle 237d10d1-6291-4bfe-accf-0f804be290a5.pdf, ou que le code source d'exemple du chapitre sur les pointeurs du cours de C s'appelle d6c22d1a-99b9-4462-b46f-41236fecb4dc.c. Aussi me paraît-il indispensable que l'on puisse donner le nom que l'on veut aux fichiers importés. Soit que le nom d'origine du fichier soit conservé, soit qu'on puisse le changer par le biais de l'interface une fois importé, selon à quel moment il est le plus pratique pour les devs d'introduire la vérification que le nom n'existe pas déjà.

Améliorer la bête

Au point où nous en sommes rendus, on aurait une médiathèque fonctionnelle et c'est amplement suffisant pour une première version de l'outil. Voici cependant quelques pistes d'amélioration pour en faire un truc vraiment surpuissant.

La question de la validation

Dans le fonctionnement actuel, il n'y a pas de vérification a priori du contenu hébergé sur ZdS. Or, ce contenu est visible même sans être connecté et même sans qu'il soit posté sur ZdS. Cela signifie qu'il est tout à fait possible de mettre sur ZdS un florilège de ses plus belles photos pornographiques afin de les partager avec ses amis sur jaimelesboobs.fr et que personne ne se rende jamais compte de rien¹. En élargissant à d'autres formats de fichiers, il devient possible d'héberger (et donc de partager) une bibliothèque entière de ePub et PDF pirates, ou des codes sources de logiciels malveillants, etc.

Dans ces conditions, il ne serait sans doute pas inutile d'introduire une forme de validation du contenu annexe hébergé. L'idée serait que, tant qu'un contenu importé n'a pas reçu l'aval de la validation, il ne soit pas possible d'y accéder directement (via son URL), mais uniquement à travers l'interface de la médiathèque (qui n'est accessible qu'à l'importateur et au staff). On pourrait alors demander la validation de tel contenu ou de telle « galerie », et la validation n'aurait qu'une case à cocher pour que les fichiers importés soient accessibles de l'extérieur. Cette autorisation deviendrait bien sûr caduque dès que le contenu serait mis à jour.

D'autres formats d'archive

Pour l'instant, on est parti sur des archives ZIP parce qu'on sait qu'il est très simple de le faire en Python. Mais il pourrait être intéressant de permettre d'importer d'autres formats d'archives, qui peuvent être plus efficaces à la compression ou avoir une utilité différente, comme les fichiers TAR, les archives GZIP, BZIP2 ou encore XZ.

En outre, il est possible de chiffrer les archives, ce qui permet de créer des fichiers OpenDocument ou OOXML en lecture seule, ce qui a bien sûr son utilité. Cependant, ce faisant, l'outil de vérification du contenu des archives ne pourrait plus y accéder : il faudrait alors permettre à l'utilisateur de fournir à l'outil de vérification le mot de passe qui verrouille son archive.

Remplacer les exports automatiques

C'est un détail, mais il serait vraiment plaisant de pouvoir remplacer le lien de téléchargement d'un article/tuto en PDF ou ePub par un lien vers un PDF ou un ePub retravaillé et importé dans sa médiathèque.

C'est à vous !

J'ai identifié par des cadres « question » tous les points sur lesquels vous pouvez intervenir, afin qu'ils soient plus repérables. Cependant, si vous pensez à autre chose, n'hésitez pas à en faire part aussi.

J'ai pas tout lu, je reprendrai demain mais en parcourant vite fait je dirais que pour les vidéos c'est inutile : ca va très vite dépasser la limite qu'on va fixer et il y a déjà le support de YouTube et dailymotion pour partager ce genre de ressource.

Deux questions que je me pose autour de ça :

1. le partage / les permissions pour une gallerie / un document.

2. Le versionning des documents.

C'est pas deux questions anodines en fait, ça fait plein plein de fois que je suis confronté à ce problème de "on veut attacher des documents à quelque chose" souvent on se dit "on verra après, on itère avec une version simple d'abord". Et au final on se retrouve avec une quasi-GED.

Soit on met ça complètement de côté et on peut partir sur une solution totalement custom. Soit ça viendra sur la table, et ça serait pas complètement fantasque d'étudier des solutions de GED existantes, voire d'en faire un projet Django disjoint (si l'ecosystème Django manque d'un module GED) et de le plugger sur le site après.

Ça permettrait à des contributeurs totalement étrangers au site d'être impliqué et ça bénéficie à tout le monde, et surtout ça permettrait d'être testable, déployable, etc. sans avoir à "rentrer" dans le code de ZdS.

Question: "GED" ??

Du reste: très bonne idée. Je rejoint l'avis de Kje sur les vidéos, et j'ai quelques réserves à exprimer sur la taille (malheureusement, de ce que j'en sais, les serveurs de ZdS n'ont pas des ressources infinies, et c'est une question qui revient de temps à autre, donc je préfère la lancer toute de suite.

Il y a aussi le fait qu'il faille interdire à tout pris certaines choses pour la sécurité. Avec toute la bonne volonté du monde, on est jamais à l'abris d'une tarbomb, par exemple, donc cette question de validation me semble peut-être nécessaire (mais va être relativement difficile à mettre en place).

Pour les permissions, il y à très longtemps, on a eu un projet d'ajouter un mode "lecture" aux galeries. On peut reprendre cette idée.

http://fr.wikipedia.org/wiki/Gestion_%C3%A9lectronique_des_documents

http://en.wikipedia.org/wiki/Document_management_system

Je suis assez d'accord avec Javier. On a déjà une large base de code. Autant ça se justifie pour article/tuto car c'est notre fond de commerce et on voulait utiliser git pour ça, autant ce genre de chose existe déjà et on gagnerait probablement a reprendre un truc existant.

Il y a quelques DMS complet et pleins de gestionnaires de galeries et fichiers qui existent.

Dans ces conditions, il ne serait sans doute pas inutile d'introduire une forme de validation du contenu annexe hébergé.

Très lourd. Si on doit valider chaque document, ça risque de prendre trop de temps. De plus, ça empêche de faire facilement des tests, donc ce n'est pas non plus pratique.

Avez-vous d'autres idées qui, à terme, pourraient améliorer le fonctionnement de la médiathèque ?

Puisqu'on en parle… À mon sens, le système de galerie est le truc le moins bien pensé du système de rédaction des tutos. Je vais copier-coller ce que je rapportais :

Note : les champs en question seraient la licence, l'auteur original avec éventuellement un lien, mais aussi un champ libre pour décrire vite-fait l'image, ou mettre des informations complémentaires.

Il pourrait être chouette d'avoir la possibilité, pour une galerie attachée à un contenu, de remplacer d'un coup toutes les url d'une image mise à jour. En effet, l'url change lors de la mise à jour et ce comportement est très bien comme ça (cf : ici). Seulement, c'est laborieux de parcourir tout le contenu pour changer les anciennes urls (bon, en principe l'image n'apparaît qu'une fois, mais c'est laborieux quand même) et avoir une fonctionnalité pour ça serait fort pratique.

Sinon, petite idée en l'air : conserver un historique d'une image. Autrement dit, pouvoir accéder à toutes ses versions, ce qui permettrait de revenir aisément sur une (série de) mise à jour. Mais je ne suis pas certain que ce soit bien utile.

Je remonte avec une petite proposition. L'attribut download permet de donner un nom à la volé à un fichier. Exemple :

1

<a href="rze-rzer-zerzer.pdf" download="mon-beau-fichier.pdf">Lien</a>

Bonjour,

Je me de completer.

Voyez-vous d'autres formats qui devraient être autorisés ? Ai-je oublié quelque chose dans ma liste ?

Pour moi, il peut etre interessand d'ajouter les images au format raw (pour du traitementè d'image par exemple), de nombreux formats d'image (Ai, par exemple). Pourquoi avoir exclu les formats audio (traitement sonore, acoustique, programme proposant de traiter un son, etc). Pourquoi pas ajouter les fichiers 3d : sketchup, 3ds max, blender, fichiers mlt, etc.

Les vidéos

Pour moi c'est le seul cas à exclure sont les vidéos car il existe des plateformes très performantes et facilement intégrables.

Concernant les limites de poids, un système de limite en fonction du type de fichier et le plus intéressant. AMHA, deux ou trois niveaux de séparation devrait suffire : inférieur à 1024Ko et entre 1024Ko et 5Mo pour certains fichiers (pdf, fichiers audios, fichiers ai ou indesign).

Ce qui doit changer

J'ai déja eu ce genre de problématique dans un contexte pro, voici la ligne de conduite que j'avais choisi (pas forcement adapté ici, mais ca donne une base de reflexion) :

• Si on ne peut pas faire de miniature on affiche un pictogramme representant le type de fichier (note pour un fichier audio, dessin pour un fichier ai, cube pour un fichier 3d, etc.)

• A terme : afficher des metadata par dessus le picto. Ce système peut etre long à implementer, car il faut un extracteur de meadaa pourchaque type de fichiers (ffplay pour les fichiers audios, par exemple) ou on se limite à des metadatas simples comme le poids. De mon point de vue, l'apport est faible pour une grosse complexité.

• Pour la gestion du nom : laisser le nom du fichier original. Pour éviter les doublons il est possible de concatener avec l'identifiant unique du média et de tronquer cet ID au moment du téléchargement pour que cela soit transparent pour l'utilisateur, ou utiliser l'attribut download (que je ne connaissais pas). Si besoin utiliser une regex pour filtrer certains types de caractères dans le nom.

Si besoin je peut reprendre la rédaction de cette ZEP, jeter un coup d'oeil au système déja existant, compiler les remarques et completer le fil.

Bonne journée, Anto59290

Ha ça me fait penser que j'avais fait un pack d'icône de fichier il y a quelques temps pour une galerie multimédia.

Je veux bien la céder gracieusement à ZDS. Je peux sans problème changer les couleurs

Et voilà l'archive avec toutes extension. (je me rends compte en l'uploadant qu'il y a majoritairement des extensions de codes mais d'autre format peuvent s'ajouter très facilement.