ZEP-28 : Médiathèque

Améliorer les galeries d'images

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet
Cartouche
ZEP 28
Titre Médiathèque
Révision 1
Date de création 2015-04-02
Dernière révision 2015-04-02
Type Feature
Statut Rédaction

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.

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

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.

Qu'en pensez-vous ? Devons-nous autoriser les formats de vidéo, lesquels et sous quelles conditions ?

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.

Ai-je oublié quelque chose dans cette liste ? Trouvez-vous qu'une de ces entrées soit abusive ?

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.

Quel est votre avis sur la question ? Quels formats devraient avoir une limite maximale différente, et laquelle ?

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à.

Vos avis ? Voyez-vous autre chose ?

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 rien1. 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.

Avez-vous d'autres idées qui, à terme, pourraient améliorer le fonctionnement de la 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.


  1. Ne rigolez pas ! Brazzers fournit des images de bonne qualité qui font aux alentours de 900-1000 Ko, alors c'est tout à fait faisable… 

#JeSuisGrimur #OnVautMieuxQueÇa

+3 -0
Staff

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.

+7 -0

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.

Édité par Javier

Happiness is a warm puppy

+0 -0

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.

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0
Staff

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 :

J'ai des images sur un site externe, sous licence libre, je veux les mettre dans un article. À l'heure actuel, je dois : (1) les enregistrer sur mon PC, (2) créer une galerie, (3) les importer, (4) copier le liens. Pire, je n'ai pas de champ « source » ou « lien » sur lequel je pourrai définir facilement les informations que je veux garder liées à l'image. Il y a bien la légende, mais elle trop courte pour une URL. Bref, il faudrait permettre l'import depuis une URL, et l'ajout d'au moins deux champs en plus de la légende.

moi

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.

Édité par Gabbro

Hier, dans le parc, j'ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+2 -0

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.

Édité par Vayel

+0 -0
Auteur du sujet

Cette ZEP est en attente d'un repreneur !

Ayant été profondément refroidi par la foire d'empoigne de la désanonymisation des +1/-1 (et d'autres avant, n'allez pas croire que c'est un coup de tête), j'ai décidé que j'avais autre chose à foutre que de me laisser emmerder pour des conneries. En conséquence de quoi, je cesse séant toute contribution à l'évolution de la plate-forme et je me contenterai désormais de produire du contenu.

Je ne demande même aucun droit de regard sur l'identité du repreneur : débrouillez-vous.

#JeSuisGrimur #OnVautMieuxQueÇa

+3 -10

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

+0 -1

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 ;)

Image utilisateur Image utilisateur Image utilisateur

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.

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte