Modèle des fichiers joints #61

Manually merged
Darks merged 3 commits from Filoji/PCv5:dev into dev 2020-08-01 21:47:33 +02:00
Collaborator

Euh ? C'est comme ça ? Sinon, voici attachement.py

Euh ? C'est comme ça ? Sinon, voici attachement.py
Owner

Quelques remarques :

  • Attachment ne prend qu'un seul e
  • Pourquoi stocker le hash en texte au lieu d'un blob binaire de type bytes() ?
  • l25, ce serait sans doute self.hash_file et pas hash_file

Les fichiers joints on les lie uniquement à des commentaires et pas à des posts ? Certainement les mécanismes vont s'appliquer aussi aux téléchargements de programmes et aux pièces jointes de tutoriels. On les considère comme les fichiers joints du top comment ? Comment on étend ça au stockage partagé des admins (la généralisation de l'adimg actuelle) ?

@Darks Opinion désirée.

Quelques remarques : * *Attachment* ne prend qu'un seul e * Pourquoi stocker le hash en texte au lieu d'un blob binaire de type `bytes()` ? * l25, ce serait sans doute `self.hash_file` et pas `hash_file` Les fichiers joints on les lie uniquement à des commentaires et pas à des posts ? Certainement les mécanismes vont s'appliquer aussi aux téléchargements de programmes et aux pièces jointes de tutoriels. On les considère comme les fichiers joints du top comment ? Comment on étend ça au stockage partagé des admins (la généralisation de l'adimg actuelle) ? @Darks Opinion désirée.
Lephenixnoir changed title from dev to Modèle des fichiers joints 2020-07-22 23:01:35 +02:00
Author
Collaborator

@Lephenixnoir : Le hash du fichier sert à renommer le fichier, mais ça je pense que tu le sais déjà. Ainsi, pour éviter les conversions inutiles, je préférais le stocker en temps que str pour ne pas se compliquer la tâche.

En effet, @Darks m'a dit qu'il fallait joindre les attachment aux commentaires, et les top commentaires. Pour ce qui est du stockage partagé des admins, il ne m'en a pas parlé, mais on peut toujours faire une fonction (pas dans attachment) qui détectera de quel image on parle. Ainsi, on liera le commentaire à l'attachment précis déjà créé.

@Lephenixnoir : Le hash du fichier sert à renommer le fichier, mais ça je pense que tu le sais déjà. Ainsi, pour éviter les conversions inutiles, je préférais le stocker en temps que `str` pour ne pas se compliquer la tâche. En effet, @Darks m'a dit qu'il fallait joindre les attachment aux commentaires, et les top commentaires. Pour ce qui est du stockage partagé des admins, il ne m'en a pas parlé, mais on peut toujours faire une fonction (pas dans attachment) qui détectera de quel image on parle. Ainsi, on liera le commentaire à l'attachment précis déjà créé.
Owner

Pour le renommage je présume qu'il serait plus malin d'avoir un dossier du type <hash>/<fichier>, de sorte que le fichier se fasse télécharger sous son nom original tout en étant servi par Nginx sans demander de passer par la bdd ?

Pour le renommage je présume qu'il serait plus malin d'avoir un dossier du type `<hash>/<fichier>`, de sorte que le fichier se fasse télécharger sous son nom original tout en étant servi par Nginx sans demander de passer par la bdd ?
Owner

Quelques remarques de mon coté

  • Déjà c'est pas trop mal, ça se présente pas mal
  • hashedhash. Pourquoi se faire chier ? Un hash c'est un hash 😛
  • Il faudrait pouvoir valider les types de fichiers autorisés. Et sans se baser sur l'extension, parce que sinon c'est troué
  • L'idée de Lephe de passer par hash/file me parait intéressante
  • Il faut quand même ajouter un attribut url (@property) pour récupérer l'URL du fichier
  • Et quoi qu'il arrive il faut vérifier que le nom du fichier soit normalisé avant de l'enregistrer (pas de path transversal hein)

Concernant l'architecture, j'ai pensé associer les fichiers qu'à des commentaires. En effet, vu l'organisation actuelle des contenus (MainPost <> Thread <> (Top)Comment), je ne vois pas les cas de figure pour lesquels ont aurait envie d'attacher des PJ à un MainPost. Pour ce qui est de l'affichage des programmes par exemple, on liste les fichiers disponibles dans le top comment du programme, et suivant le type de fichier on l'affiche différemment (images, programmes, documentation, etc.).

Ce système me parait plus souple (on garde l'historique des versions de programmes dans les commentaires), plus facile à utiliser pour tout le monde, et plus facile à gérer au niveau du code.

Quelques remarques de mon coté - Déjà c'est pas trop mal, ça se présente pas mal - `hashed` → `hash`. Pourquoi se faire chier ? Un hash c'est un `hash` :stuck_out_tongue: - Il faudrait pouvoir valider les types de fichiers autorisés. Et sans se baser sur l'extension, parce que sinon c'est troué - L'idée de Lephe de passer par `hash/file` me parait intéressante - Il faut quand même ajouter un attribut `url` (`@property`) pour récupérer l'URL du fichier - Et quoi qu'il arrive il faut vérifier que le nom du fichier soit normalisé avant de l'enregistrer (pas de path transversal hein) Concernant l'architecture, j'ai pensé associer les fichiers qu'à des commentaires. En effet, vu l'organisation actuelle des contenus (MainPost <> Thread <> (Top)Comment), je ne vois pas les cas de figure pour lesquels ont aurait envie d'attacher des PJ à un MainPost. Pour ce qui est de l'affichage des programmes par exemple, on liste les fichiers disponibles dans le top comment du programme, et suivant le type de fichier on l'affiche différemment (images, programmes, documentation, etc.). Ce système me parait plus souple (on garde l'historique des versions de programmes dans les commentaires), plus facile à utiliser pour tout le monde, et plus facile à gérer au niveau du code.
Owner

Il faudrait pouvoir valider les types de fichiers autorisés. Et sans se baser sur l'extension, parce que sinon c'est troué

Je ne vois pas le problème étant donné que le serveur web décide de la façon de servir les fichiers selon leur extension, et que l'OS de l'utilisateur qui télécharge un fichier va faire pareil.

Pour moi ça ne sert que si tu veux afficher le contenu d'un g1m ou une fonctionnalité nouvelle du genre.

En effet, vu l'organisation actuelle des contenus (MainPost <> Thread <> (Top)Comment), je ne vois pas les cas de figure pour lesquels ont aurait envie d'attacher des PJ à un MainPost.

Si je ne me trompe pas en disant MainPost = Program/Tutorial/Topic, alors on a une raison simple de vouloir mettre des PJ : fournir les fichiers en téléchargement au programme. Tu peux dire "les fichiers du top comment d'un programme sont les fichiers en téléchargement", auquel cas ok, et les anciennes versions des programmes resteront disponibles en téléchargement lorsque la description sera réécrite. Mais les autres métadonnées comme l'image, le numéro de version, la taille ou la catégorie ne le seront pas, ce qui fait un peu bizarre.

> Il faudrait pouvoir valider les types de fichiers autorisés. Et sans se baser sur l'extension, parce que sinon c'est troué Je ne vois pas le problème étant donné que le serveur web décide de la façon de servir les fichiers selon leur extension, et que l'OS de l'utilisateur qui télécharge un fichier va faire pareil. Pour moi ça ne sert que si tu veux afficher le contenu d'un g1m ou une fonctionnalité nouvelle du genre. > En effet, vu l'organisation actuelle des contenus (MainPost <> Thread <> (Top)Comment), je ne vois pas les cas de figure pour lesquels ont aurait envie d'attacher des PJ à un MainPost. Si je ne me trompe pas en disant MainPost = Program/Tutorial/Topic, alors on a une raison simple de vouloir mettre des PJ : fournir les fichiers en téléchargement au programme. Tu peux dire "les fichiers du top comment d'un programme sont les fichiers en téléchargement", auquel cas ok, et les anciennes versions des programmes resteront disponibles en téléchargement lorsque la description sera réécrite. Mais les autres métadonnées comme l'image, le numéro de version, la taille ou la catégorie ne le seront pas, ce qui fait un peu bizarre.
Owner

Tu peux dire “les fichiers du top comment d'un programme sont les fichiers en téléchargement”, auquel cas ok, et les anciennes versions des programmes resteront disponibles en téléchargement lorsque la description sera réécrite

C'est ce à quoi je pense. La description d'un programme, c'est le top comment du thread associé. C'est plus cohérent avec le fonctionnement du forum (et donc plus simple quand il s'agira de migrer un topic vers un programme.

Mais les autres métadonnées comme l'image, le numéro de version, la taille ou la catégorie ne le seront pas, ce qui fait un peu bizarre.

Pour l'image, je pensais chercher les images en PJ du top comment. Par contre pour la taille, le numéro de version et la catégorie, on n'aura pas l'historique. J'aurais tendance à dire que ce n'est pas critique.

  • La taille est une donnée assez annexe, donc si on perd son historique, pas grave
  • L'historique de la numérotation des versions de programmes n'est pas important si on a le suivi des versions dans le fil de commentaires
  • Je ne vois pas d'intérêt à versionner la catégorie
  • Pour les autres métadonnées, je reste à l'écoute

Pour moi ça ne sert que si tu veux afficher le contenu d'un g1m ou une fonctionnalité nouvelle du genre.

Le but étant de traiter les fichiers selon leurs types, je voudrais être sûr qu'on puisse pas exécuter du Js parce qu'on a uploadé un fichier .png crafté. De même on peut vouloir générer des aperçus avec PIL, donc à voir comment on sécurise le bouzin. Si tu penses que se baser uniquement sur l'extension et des exceptions bien gérées est suffisant, soit.

––– Edit –––

Je ne vois pas le problème étant donné que le serveur web décide de la façon de servir les fichiers selon leur extension

Ça se base pas sur le type MIME justement ? Anyway…

> Tu peux dire “les fichiers du top comment d'un programme sont les fichiers en téléchargement”, auquel cas ok, et les anciennes versions des programmes resteront disponibles en téléchargement lorsque la description sera réécrite C'est ce à quoi je pense. La description d'un programme, c'est le top comment du thread associé. C'est plus cohérent avec le fonctionnement du forum (et donc plus simple quand il s'agira de migrer un topic vers un programme. > Mais les autres métadonnées comme l'image, le numéro de version, la taille ou la catégorie ne le seront pas, ce qui fait un peu bizarre. Pour l'image, je pensais chercher les images en PJ du top comment. Par contre pour la taille, le numéro de version et la catégorie, on n'aura pas l'historique. J'aurais tendance à dire que ce n'est pas critique. - La taille est une donnée assez annexe, donc si on perd son historique, pas grave - L'historique de la *numérotation* des versions de programmes n'est pas important si on a le suivi des *versions* dans le fil de commentaires - Je ne vois pas d'intérêt à versionner la catégorie - Pour les autres métadonnées, je reste à l'écoute > Pour moi ça ne sert que si tu veux afficher le contenu d'un g1m ou une fonctionnalité nouvelle du genre. Le but étant de traiter les fichiers selon leurs types, je voudrais être sûr qu'on puisse pas exécuter du Js parce qu'on a uploadé un fichier `.png` crafté. De même on peut vouloir générer des aperçus avec PIL, donc à voir comment on sécurise le bouzin. Si tu penses que se baser uniquement sur l'extension et des exceptions bien gérées est suffisant, soit. ––– Edit ––– > Je ne vois pas le problème étant donné que le serveur web décide de la façon de servir les fichiers selon leur extension Ça se base pas sur le type MIME justement ? Anyway…
Owner

Pour l'image, je pensais chercher les images en PJ du top comment.

Ça pourrait me convenir mais j'ai quand même des doutes. Tu vois, ça me paraîtrait normal d'insérer des images supplémentaires dans la description ne serait-ce que parce que l'image de présentation est un GIF ou parce que les dimensions ne correspondent peut-être pas. Perso j'aimerais bien faire ça dans mes propres programmes.

Dans ce cas, la "détection" de l'image de présentation paraît pas évidente. Tu peux dire "c'est la première", auquel cas il faut les ordonner. Tu peux ajouter une métadonnée au programme avec la référence à l'Attachment associé, dans ce cas c'est perdu quand on réécrit la description (ce qui n'est pas grave, la référence à l'Attachment me dérange plus TBH).

Par contre pour la taille, le numéro de version et la catégorie, on n'aura pas l'historique. J'aurais tendance à dire que ce n'est pas critique.

Oui en fait je te rejoins là-dessus, la taille ça devrait être automatique, la version il suffit de compter le nombre de PP (dans le Thread ?), et la catégorie on s'en fout. Les notes, progrank, etc, pareil. Faut juste s'en souvenir pour faire prendre des mauvaises surprises je suppose.

Le but étant de traiter les fichiers selon leurs types, je voudrais être sûr qu'on puisse pas exécuter du Js parce qu'on a uploadé un fichier .png crafté. De même on peut vouloir générer des aperçus avec PIL, donc à voir comment on sécurise le bouzin. Si tu penses que se baser uniquement sur l'extension et des exceptions bien gérées est suffisant, soit.

Si l'extension est .png, le logiciel qui l'ouvre ne peut pas savoir que c'est du JS (en plus s'il y a suffisamment peu de code ça pourrait être du Python) et encore moins l'exécuter. Je pense que c'est pas plus dangereux que tout le reste du web, donc disons au moins suffisant dans un premier temps.

Dès qu'il y a des fonctionnalité supplémentaires (eg. aperçus), c'est une autre affaire on est bien d'accord. Mais pour le reste je pense qu'il est suffisant de filtrer par extension.

> Pour l'image, je pensais chercher les images en PJ du top comment. Ça pourrait me convenir mais j'ai quand même des doutes. Tu vois, ça me paraîtrait normal d'insérer des images supplémentaires dans la description ne serait-ce que parce que l'image de présentation est un GIF ou parce que les dimensions ne correspondent peut-être pas. Perso j'aimerais bien faire ça dans mes propres programmes. Dans ce cas, la "détection" de l'image de présentation paraît pas évidente. Tu peux dire "c'est la première", auquel cas il faut les ordonner. Tu peux ajouter une métadonnée au programme avec la référence à l'Attachment associé, dans ce cas c'est perdu quand on réécrit la description (ce qui n'est pas grave, la référence à l'Attachment me dérange plus TBH). > Par contre pour la taille, le numéro de version et la catégorie, on n'aura pas l'historique. J'aurais tendance à dire que ce n'est pas critique. Oui en fait je te rejoins là-dessus, la taille ça devrait être automatique, la version il suffit de compter le nombre de PP (dans le Thread ?), et la catégorie on s'en fout. Les notes, progrank, etc, pareil. Faut juste s'en souvenir pour faire prendre des mauvaises surprises je suppose. > Le but étant de traiter les fichiers selon leurs types, je voudrais être sûr qu'on puisse pas exécuter du Js parce qu'on a uploadé un fichier .png crafté. De même on peut vouloir générer des aperçus avec PIL, donc à voir comment on sécurise le bouzin. Si tu penses que se baser uniquement sur l'extension et des exceptions bien gérées est suffisant, soit. Si l'extension est `.png`, le logiciel qui l'ouvre ne peut pas savoir que c'est du JS (en plus s'il y a suffisamment peu de code ça pourrait être du Python) et encore moins l'exécuter. Je pense que c'est pas plus dangereux que tout le reste du web, donc disons au moins suffisant dans un premier temps. Dès qu'il y a des fonctionnalité supplémentaires (eg. aperçus), c'est une autre affaire on est bien d'accord. Mais pour le reste je pense qu'il est suffisant de filtrer par extension.
Owner

J'ai l'impression que tu pars du principe qu'un programme ne peut avoir qu'une image de présentation.

J'avais plutôt en tête une galerie d'images associée au programme (comme sur les stores d'app par exemple). Pour ce qui est de l'image de présentation dans la liste des programmes, je vois plusieurs solutions :

  1. On en affiche une aléatoirement
  2. On en affiche une via un flag dans la propriété du fichier
  3. On génère un gif à partir des images du top comment
  4. On ajoute une image dans l'objet Program

L'option 1 est la plus simple à mettre en place mais n'est pas satisfaisante pour les auteurs de programmes.

L'option 2 ajoute un peu de complexité, mais reste facilement implémentable. En plus ça peut s'appliquer de manière élégante au news (si on affiche un résumé en page d'accueil, on peut récupérer l'image principale via ce même flag).

L'option 3 est assez élégante, mais c'est un joli défi technique pour avoir un procédé fiable (qu'est-ce qu'on fait si on mélange un png avec un gif ?)

L'option 4 est la plus triviale, mais ne permet pas la mise à jour automatique du programme lorsqu'un nouveau top comment est choisi.

–––

Personnellement je préfère l'option 2, parce qu'elle est réutilisable ailleurs de manère élégante.

J'ai l'impression que tu pars du principe qu'un programme ne peut avoir qu'une image de présentation. J'avais plutôt en tête une galerie d'images associée au programme (comme sur les stores d'app par exemple). Pour ce qui est de l'image de présentation dans la liste des programmes, je vois plusieurs solutions : 1. On en affiche une aléatoirement 2. On en affiche une via un flag dans la propriété du fichier 3. On génère un gif à partir des images du top comment 4. On ajoute une image dans l'objet `Program` L'option 1 est la plus simple à mettre en place mais n'est pas satisfaisante pour les auteurs de programmes. L'option 2 ajoute un peu de complexité, mais reste facilement implémentable. En plus ça peut s'appliquer de manière élégante au news (si on affiche un résumé en page d'accueil, on peut récupérer l'image principale via ce même flag). L'option 3 est assez élégante, mais c'est un joli défi technique pour avoir un procédé fiable (qu'est-ce qu'on fait si on mélange un png avec un gif ?) L'option 4 est la plus triviale, mais ne permet pas la mise à jour automatique du programme lorsqu'un nouveau top comment est choisi. ––– Personnellement je préfère l'option 2, parce qu'elle est réutilisable ailleurs de manère élégante.
Owner

C'est vrai, je supposais ça. Je propose la solution 2 aussi, parce que comme ça on peut avoir des images dans la description sans les avoir dans la présentation (et inversement). Et on peut toujours faire le GIF à la main avant.

Dans ce cas est-ce qu'il ne faudrait pas structurer un peu les fichiers joints ? Au moins pouvoir donner un ordre aux fichiers en téléchargement me paraît le minimum. Dans ce cas je pense qu'Attachment a besoin d'un peu plus d'infos (catégoriser images/téléchargements, ordonner, etc).

C'est vrai, je supposais ça. Je propose la solution 2 aussi, parce que comme ça on peut avoir des images dans la description sans les avoir dans la présentation (et inversement). Et on peut toujours faire le GIF à la main avant. Dans ce cas est-ce qu'il ne faudrait pas structurer un peu les fichiers joints ? Au moins pouvoir donner un ordre aux fichiers en téléchargement me paraît le minimum. Dans ce cas je pense qu'Attachment a besoin d'un peu plus d'infos (catégoriser images/téléchargements, ordonner, etc).
Owner

Catégorie

On doit pouvoir se baser sur le type de fichier (donc l'extension) pour savoir si on affiche l'image, propose le fichier au téléchargement, voir même propose une preview du code. Pas besoin selon moi d'ajouter une métadonnée supplémentaire à ce niveau là.

Ceci dit ça n'empêche pas de stocker l'extension en bdd pour optimiser les opérations dessus.

Priorité

On peut se débrouiller pour stocker un entier priority dans avec chaque fichier. À l'affichage, on trie par priorité. Si deux fichiers du même commentaire on la même priorité, alors l'ordre est indéfini entre les deux.

Exemple

Je poste un programme, dont le top comment contient ces fichiers :

  • image.gif : 10
  • mono.g1a : 3
  • color.g3a : 2
  • tutoriel.md : 1
  • jeu.png : 0
  • menu.png : 0
  • licence.md : 0

On affiche alors :

  • dans la description les fichiers téléchargeables, dans cet ordre : mono.g1a, color.g3a, tutorial.md, license.md.
  • dans la galerie les images dans cet ordre : image.gif, menu.png, jeu.png

Ce qui n'empêche d'ailleurs pas de réutiliser les images avec la balise image pour les inclure dans le corps du message.

Et dans la liste des programmes, on utilise l'image image.gif car c'est le fichier qui 1. est une image 2. a la plus haute priorité

#### Catégorie On doit pouvoir se baser sur le type de fichier (donc l'extension) pour savoir si on affiche l'image, propose le fichier au téléchargement, voir même propose une preview du code. Pas besoin selon moi d'ajouter une métadonnée supplémentaire à ce niveau là. Ceci dit ça n'empêche pas de stocker l'extension en bdd pour optimiser les opérations dessus. #### Priorité On peut se débrouiller pour stocker un entier `priority` dans avec chaque fichier. À l'affichage, on trie par priorité. Si deux fichiers du même commentaire on la même priorité, alors l'ordre est indéfini entre les deux. #### Exemple Je poste un programme, dont le top comment contient ces fichiers : - image.gif : 10 - mono.g1a : 3 - color.g3a : 2 - tutoriel.md : 1 - jeu.png : 0 - menu.png : 0 - licence.md : 0 On affiche alors : - dans la description les fichiers téléchargeables, dans cet ordre : `mono.g1a`, `color.g3a`, `tutorial.md`, `license.md`. - dans la galerie les images dans cet ordre : `image.gif`, `menu.png`, `jeu.png` Ce qui n'empêche d'ailleurs pas de réutiliser les images avec la balise image pour les inclure dans le corps du message. Et dans la liste des programmes, on utilise l'image `image.gif` car c'est le fichier qui 1. est une image 2. a la plus haute priorité
Owner

On doit pouvoir se baser sur le type de fichier (donc l'extension) pour savoir si on affiche l'image, propose le fichier au téléchargement, voir même propose une preview du code.

Mais ça ne te permet pas forcément d'avoir une image en fichier joint d'un tutoriel, alors que par exemple tu peux vouloir fournir un asset pour ajouter à un un add-in. Je pense que tu vois à quel point c'est inflexible.

On peut se débrouiller pour stocker un entier priority dans avec chaque fichier. À l'affichage, on trie par priorité. Si deux fichiers du même commentaire on la même priorité, alors l'ordre est indéfini entre les deux.

Pourquoi pas simplement faire des PJ une liste (donc ordonnée) ? Ça me paraît beaucoup plus naturel. Il suffit que le formulaire où tu indiques les PJs les mentionne dans un ordre précis.

> On doit pouvoir se baser sur le type de fichier (donc l'extension) pour savoir si on affiche l'image, propose le fichier au téléchargement, voir même propose une preview du code. Mais ça ne te permet pas forcément d'avoir une image en fichier joint d'un tutoriel, alors que par exemple tu peux vouloir fournir un asset pour ajouter à un un add-in. Je pense que tu vois à quel point c'est inflexible. > On peut se débrouiller pour stocker un entier priority dans avec chaque fichier. À l'affichage, on trie par priorité. Si deux fichiers du même commentaire on la même priorité, alors l'ordre est indéfini entre les deux. Pourquoi pas simplement faire des PJ une liste (donc ordonnée) ? Ça me paraît beaucoup plus naturel. Il suffit que le formulaire où tu indiques les PJs les mentionne dans un ordre précis.
Owner

Mais ça ne te permet pas forcément d'avoir une image en fichier joint d'un tutoriel, alors que par exemple tu peux vouloir fournir un asset pour ajouter à un un add-in. Je pense que tu vois à quel point c'est inflexible.

Hmm. Essayons ceci :

  • toutes les pièces-jointes du message s'affichent en bas du message. Si on clique dessus, ça les télécharge.
  • l'auteur peut mettre un lien de téléchargement [télécharger](lien) ou afficher une image ![alt](lien) même si le lien pointe vers le même fichier
  • pour la liste des PJ en bas du message, on peut faire une galerie avec la prévisualisation des fichiers images, une icone pour les fichiers binaires, la prévisualisation des fichiers de code, etc. ; avec un bouton « Télécharger » si y'a une prévisualisation.

Dans tous les cas au niveau du serveur web, il faut que tous les fichiers soient servis téléchargés, sinon ça veut dire proxifier les requêtes vers ceux-ci dans Flask. Et ça on était moyen chaud.

Pourquoi pas simplement faire des PJ une liste (donc ordonnée) ?

Parce que c'est beaucoup plus simple de gérer un entier qu'une liste ordonnée, tant au niveau du back que du front. Après le concept de liste me dérange pas, c'est juste que faire un formulaire pour ordonner des choix, c'est (très) relou soit pour le programmeur, soit pour l'utilisateur, soit les deux en même temps. Et encore plus si on se contraint à être fonctionnel même sans Js. KISS.

> Mais ça ne te permet pas forcément d'avoir une image en fichier joint d'un tutoriel, alors que par exemple tu peux vouloir fournir un asset pour ajouter à un un add-in. Je pense que tu vois à quel point c'est inflexible. Hmm. Essayons ceci : - toutes les pièces-jointes du message s'affichent en bas du message. Si on clique dessus, ça les télécharge. - l'auteur peut mettre un lien de téléchargement `[télécharger](lien)` ou afficher une image `![alt](lien)` même si le lien pointe vers le même fichier - pour la liste des PJ en bas du message, on peut faire une galerie avec la prévisualisation des fichiers images, une icone pour les fichiers binaires, la prévisualisation des fichiers de code, etc. ; avec un bouton « Télécharger » si y'a une prévisualisation. Dans tous les cas au niveau du serveur web, il faut que tous les fichiers soient servis téléchargés, sinon ça veut dire proxifier les requêtes vers ceux-ci dans Flask. Et ça on était moyen chaud. > Pourquoi pas simplement faire des PJ une liste (donc ordonnée) ? Parce que c'est beaucoup plus simple de gérer un entier qu'une liste ordonnée, tant au niveau du back que du front. Après le concept de liste me dérange pas, c'est juste que faire un formulaire pour ordonner des choix, c'est (très) relou soit pour le programmeur, soit pour l'utilisateur, soit les deux en même temps. Et encore plus si on se contraint à être fonctionnel même sans Js. KISS.
Owner

... Je sais pas, pour être honnête. J'ai l'impression qu'on invente des automatismes pétés pour rien parce qu'une fois sur 3 ça fera pas ce qu'on veut. Dans ma description de jeu je voudrais mettre des petites images ou des GIFs pour montrer un peu le gameplay, mais elles ne sont pas à télécharger, elles ne sont pas dans la présentation du programme, et ça ne sert à rien de les voir en bas (pas plus que ça ne sert de voir les images embedded dans un mail HTML en PJ).

Pourquoi ne pas contrôler tout ça proprement dans le modèle et laisser l'utilisateur faire quitte à mettre des défauts utiles ? Y'a pas des milliers de paramètres non plus.

Je pense que ça tout montre de toute façon que le modèle de la PJ toute seule n'est pas suffisant pour les besoins des programmes et tutoriels. Et j'ajouterai que je ne le pense pas suffisant non plus pour la gestion des fichiers partagés style adimg. Donc j'ai peu d'espoir de laisser le modèle comme ça et filer.

Désolé de prolonger la discussion mais y'a trop d'angles à arrondir pour que je soit vraiment confiant avec ces choix-ci.

Parce que c'est beaucoup plus simple de gérer un entier qu'une liste ordonnée, tant au niveau du back que du front.

Absolument, mais depuis quand on sacrifie la fonctionnalité pour le besoin de trivialiser l'implémentation ? Tu as omis de citer la perception de l'utilisateur lambda là-dedans qui n'a aucune idée de ce que la "priorité" va être. Faire une liste ce n'est pas seulement une question de fonctionnalité mais aussi une question de bonne GUI.

... Je sais pas, pour être honnête. J'ai l'impression qu'on invente des automatismes pétés pour rien parce qu'une fois sur 3 ça fera pas ce qu'on veut. Dans ma description de jeu je voudrais mettre des petites images ou des GIFs pour montrer un peu le gameplay, mais elles ne sont pas à télécharger, elles ne sont pas dans la présentation du programme, et ça ne sert à rien de les voir en bas (pas plus que ça ne sert de voir les images embedded dans un mail HTML en PJ). Pourquoi ne pas contrôler tout ça proprement dans le modèle et laisser l'utilisateur faire quitte à mettre des défauts utiles ? Y'a pas des milliers de paramètres non plus. Je pense que ça tout montre de toute façon que le modèle de la PJ toute seule n'est pas suffisant pour les besoins des programmes et tutoriels. Et j'ajouterai que je ne le pense pas suffisant non plus pour la gestion des fichiers partagés style adimg. Donc j'ai peu d'espoir de laisser le modèle comme ça et filer. Désolé de prolonger la discussion mais y'a trop d'angles à arrondir pour que je soit vraiment confiant avec ces choix-ci. > Parce que c'est beaucoup plus simple de gérer un entier qu'une liste ordonnée, tant au niveau du back que du front. Absolument, mais depuis quand on sacrifie la fonctionnalité pour le besoin de trivialiser l'implémentation ? Tu as omis de citer la perception de l'utilisateur lambda là-dedans qui n'a aucune idée de ce que la "priorité" va être. Faire une liste ce n'est pas seulement une question de fonctionnalité mais aussi une question de bonne GUI.
Owner

Et un flag hidden ? Si c'est hidden on l'affiche pas en bas. Le reste ne changerai pas par rapport à ma proposition.

Et j'ajouterai que je ne le pense pas suffisant non plus pour la gestion des fichiers partagés style adimg

Je ne suis pas sûr de la pertinence des fichiers adimg dans la v5. Enfin… On peut toujours reproduire le concept sur une partie dédiée, je ne suis pas sûr que le modèle Attachment s'y appliquera quoi qu'il arrive.

Désolé de prolonger la discussion mais y'a trop d'angles à arrondir pour que je soit vraiment confiant avec ces choix-ci.

Vaut mieux la prolonger maintenant qu'une fois que ce sera implémenté… :-°

Faire une liste ce n'est pas seulement une question de fonctionnalité mais aussi une question de bonne GUI.

Dans ce cas ok, mais tu t'occupe de la réalisation d'un formulaire facile à utiliser, avec un minimum de Js.

Et un flag `hidden` ? Si c'est hidden on l'affiche pas en bas. Le reste ne changerai pas par rapport à ma proposition. > Et j'ajouterai que je ne le pense pas suffisant non plus pour la gestion des fichiers partagés style adimg Je ne suis pas sûr de la pertinence des fichiers `adimg` dans la v5. Enfin… On peut toujours reproduire le concept sur une partie dédiée, je ne suis pas sûr que le modèle Attachment s'y appliquera quoi qu'il arrive. > Désolé de prolonger la discussion mais y'a trop d'angles à arrondir pour que je soit vraiment confiant avec ces choix-ci. Vaut mieux la prolonger maintenant qu'une fois que ce sera implémenté… :-° > Faire une liste ce n'est pas seulement une question de fonctionnalité mais aussi une question de bonne GUI. Dans ce cas ok, mais tu t'occupe de la réalisation d'un formulaire facile à utiliser, avec un minimum de Js.
Owner

Et un flag hidden ? Si c'est hidden on l'affiche pas en bas. Le reste ne changerai pas par rapport à ma proposition.

C'est un bon progrès ; je ne vois pas de cas particulier que cette proposition amendée ne gère pas (même si je parie qu'il en apparaîtra).

L'idée que les pages de programmes ne gèrent pas mieux les fichiers que les messages quelconques me gêne un peu en fait. J'ai un peu peur que les versions successives arrivent dans les commentaires et que la description du programme soit délaissée pour faire un gros topic en rolling release par flemme. Y'a pas ce risque dans la v42.

Pareil pour les abus dans les commentaires si c'est aussi puissant que ça, par exemple les limites de nombre et tailles de fichiers devraient pas être les mêmes entre les téléchargements d'un programme et les commentaires normaux. Mais si on archive tous les dls dans les commentaires on peut bypass ça et poser des problèmes de stockage en toute bonne foi.

(Quelque part c'est un peu l'extension de refuser les pièces jointes dans les MP, bien que moins extrême.)

Et pour revenir à la pertinence d'adimg et affiliés, on a bien besoin d'une façon de stocker des fichiers qui ne soit pas juste dans des commentaires. Il y a notamment des fichiers "statiques" comme les guides en PDF, des images partagées un peu partout comme la coupe du JDM, et j'aimerais accessoirement qu'on puisse "archiver" quelques fichiers comme des vieux manuels et autres raretés qui se perdent souvent avec le temps.

Bref, je vois vraiment pas comment on peut s'en tirer honorablement avec un seul niveau de traitement des fichiers. >_o

Dans ce cas ok, mais tu t'occupe de la réalisation d'un formulaire facile à utiliser, avec un minimum de Js.

J'apprécie l'edit, j'avais des idées pour une version avec absolument zéro JS mais il fallait interagir avec le serveur beaucoup plus souvent. J'ai des idées mais on en reparlera quand on sera d'accord sur le modèle je suppose.

> Et un flag hidden ? Si c'est hidden on l'affiche pas en bas. Le reste ne changerai pas par rapport à ma proposition. C'est un bon progrès ; je ne vois pas de cas particulier que cette proposition amendée ne gère pas (même si je parie qu'il en apparaîtra). L'idée que les pages de programmes ne gèrent pas mieux les fichiers que les messages quelconques me gêne un peu en fait. J'ai un peu peur que les versions successives arrivent dans les commentaires et que la description du programme soit délaissée pour faire un gros topic en rolling release par flemme. Y'a pas ce risque dans la v42. Pareil pour les abus dans les commentaires si c'est aussi puissant que ça, par exemple les limites de nombre et tailles de fichiers devraient pas être les mêmes entre les téléchargements d'un programme et les commentaires normaux. Mais si on archive tous les dls dans les commentaires on peut bypass ça et poser des problèmes de stockage en toute bonne foi. (Quelque part c'est un peu l'extension de refuser les pièces jointes dans les MP, bien que moins extrême.) Et pour revenir à la pertinence d'adimg et affiliés, on a bien besoin d'une façon de stocker des fichiers qui ne soit pas juste dans des commentaires. Il y a notamment des fichiers "statiques" comme les guides en PDF, des images partagées un peu partout comme la coupe du JDM, et j'aimerais accessoirement qu'on puisse "archiver" quelques fichiers comme des vieux manuels et autres raretés qui se perdent souvent avec le temps. Bref, je vois vraiment pas comment on peut s'en tirer honorablement avec un seul niveau de traitement des fichiers. >\_o > Dans ce cas ok, mais tu t'occupe de la réalisation d'un formulaire facile à utiliser, avec un minimum de Js. J'apprécie l'edit, j'avais des idées pour une version avec absolument zéro JS mais il fallait interagir avec le serveur beaucoup plus souvent. J'ai des idées mais on en reparlera quand on sera d'accord sur le modèle je suppose.
Owner

je ne vois pas de cas particulier que cette proposition amendée ne gère pas (même si je parie qu'il en apparaîtra).

Si tu as une propal qui prends en compte tout les cas de figure, tout en étant assez permissive mais pas trop chiante à maintenir, vas-y hein… x)

J'ai un peu peur que les versions successives arrivent dans les commentaires et que la description du programme soit délaissée pour faire un gros topic en rolling release par flemme

Dans tous les cas il faudra bien que les versions successives arrivent dans les commentaires. Je trouverai ça dommage d'en perdre le fil. Surtout que ça rentre pile dans le cas du commentaire qui n'est pas raccord avec le top comment. ("Oh génial, par contre la boule bouge bizarrement — J'ai udpate le programme en remplaçant la boule par un cube")

par exemple les limites de nombre et tailles de fichiers devraient pas être les mêmes entre les téléchargements d'un programme et les commentaires normaux.

Là je suis pas d'accord. Pourquoi un commentaire construit sur un topic présentant l'avancement d'un projet imposant ne pourrait pas bénéficiers d'autant de place qu'un programme ? Si on fait ça on va repartir dans le mode v42, postant plusieurs messages pour héberger plusieurs images.

J'aurai tendance à dire qu'on ne devrait pas limiter les PJ à priori mais à postériori (avec la page d'admin qui va bien). Qu'on autorise ou non les PJ dans les MP d'ailleurs.

Et pour revenir à la pertinence d'adimg et affiliés, on a bien besoin d'une façon de stocker des fichiers qui ne soit pas juste dans des commentaires

Ok, mais ça nécessite une app de stockage de fichiers, donc c'est un peu hors-sujet, ici on traite des pièces-jointes des commentaires, et par extension – si on s'accorde pas sur un autre modèle – des programmes, tutoriels et autres.


Il est vrai que j'ai pas pensé au problèmes du nombre de téléchargements, etc. Si tu as autre chose de plus polyvalent et qui sera pas trop usine à gaz, à voir…

> je ne vois pas de cas particulier que cette proposition amendée ne gère pas (même si je parie qu'il en apparaîtra). Si tu as une propal qui prends en compte tout les cas de figure, tout en étant assez permissive mais pas trop chiante à maintenir, vas-y hein… x) > J'ai un peu peur que les versions successives arrivent dans les commentaires et que la description du programme soit délaissée pour faire un gros topic en rolling release par flemme Dans tous les cas il faudra bien que les versions successives arrivent dans les commentaires. Je trouverai ça dommage d'en perdre le fil. Surtout que ça rentre pile dans le cas du commentaire qui n'est pas raccord avec le top comment. ("Oh génial, par contre la boule bouge bizarrement — J'ai udpate le programme en remplaçant la boule par un cube") > par exemple les limites de nombre et tailles de fichiers devraient pas être les mêmes entre les téléchargements d'un programme et les commentaires normaux. Là je suis pas d'accord. Pourquoi un commentaire construit sur un topic présentant l'avancement d'un projet imposant ne pourrait pas bénéficiers d'autant de place qu'un programme ? Si on fait ça on va repartir dans le mode v42, postant plusieurs messages pour héberger plusieurs images. J'aurai tendance à dire qu'on ne devrait pas limiter les PJ à priori mais à postériori (avec la page d'admin qui va bien). Qu'on autorise ou non les PJ dans les MP d'ailleurs. > Et pour revenir à la pertinence d'adimg et affiliés, on a bien besoin d'une façon de stocker des fichiers qui ne soit pas juste dans des commentaires Ok, mais ça nécessite une app de stockage de fichiers, donc c'est un peu hors-sujet, ici on traite des pièces-jointes des commentaires, et par extension – si on s'accorde pas sur un autre modèle – des programmes, tutoriels et autres. --- Il est vrai que j'ai pas pensé au problèmes du nombre de téléchargements, etc. Si tu as autre chose de plus polyvalent et qui sera pas trop usine à gaz, à voir…
Owner

Si tu as une propal qui prends en compte tout les cas de figure, tout en étant assez permissive mais pas trop chiante à maintenir, vas-y hein… x)

Disons que pour ce qui est des programmes/tutoriels/etc je pense qu'il est élégant d'ajouter des propriétés dans le modèle pour laisser de latitude à l'utilisateur plutôt que de tout faire en automatique. D'ailleurs on est tombés sur ça au moins deux fois : pour la sélection de l'image de présentation d'un programme et pour les fichiers cachés par défaut.

J'ai eu un peu l'impression que ça te dérangeait notamment quand tu as dit ça, ce qui ne me paraît pas vraiment naturel.

Pour l'image, je pensais chercher les images en PJ du top comment.


Dans tous les cas il faudra bien que les versions successives arrivent dans les commentaires. Je trouverai ça dommage d'en perdre le fil.

Ça pose quand même un léger problème de stockage (ce que je n'ai pas réalisé tout de suite). Les plus gros projets sont aussi ceux qui sont modifiés le plus, et un add-in Prizm ça fait vite 2 Mo par fichier par version.

Personnellement ça ne me paraît pas abusif d'archiver ainsi les versions de programmes, mais pour les commentaires génériques je suis convaincu qu'il faut des limites plus strictes. Par exemple les logiciels actuels font jusqu'à plus de 50 Mo (ClassPad Manager). Tu peux clairement pas te permettre de mettre cette limite partout dans les commentaires d'un topic random, ça poserait autant de problèmes d'abus sur le stockage que sur la taille des requêtes et la bande passante du serveur.

Là je suis pas d'accord. Pourquoi un commentaire construit sur un topic présentant l'avancement d'un projet imposant ne pourrait pas bénéficiers d'autant de place qu'un programme ?

Bien sûr, quand l'auteur d'un projet poste des updates sur ce projet, pas de raison de se priver. Mais ce n'est pas le commentaire random d'un invité qui poste sur un topic qu'il n'a jamais lu, cas qui dans ta proposition autorise les mêmes limites.

Mon intuition est d'autoriser un stockage conséquent pour le topic au lieu de ses commentaires, ce qui permet à l'auteur de faire ce qu'il veut sans pour autant ouvrir la porte à toutes les dérives.

Pour ce qui est des archives d'anciens post principaux, on les comptabiliserait alors simplement dans les limites du topic/programme sans appliquer les limites plus restrictives que je propose sur les commentaires quelconques. En outre, cela résoud le risque que j'avais évoqué que les versions soient publiées juste en commentaire car les gros fichiers ne peuvent être ajoutés que si un nouveau post principal est écrit.

Si on fait ça on va repartir dans le mode v42, postant plusieurs messages pour héberger plusieurs images.

Je décèle une pente glissante ici, tu sais bien que je considère cette limite de la v42 comme un problème et que je ne proposerais pas un système qui nous oblige à faire ça.

J'aurai tendance à dire qu'on ne devrait pas limiter les PJ à priori mais à postériori (avec la page d'admin qui va bien). Qu'on autorise ou non les PJ dans les MP d'ailleurs.

Je garde bien ça à l'oeil, mais outre les enjeux de PJ dans les MP qui posent des questions de confidentialité, il reste le problème de la bande passante et de la réactivité du serveur qui peut en prendre un coup.

Ok, mais ça nécessite une app de stockage de fichiers, donc c'est un peu hors-sujet, ici on traite des pièces-jointes des commentaires, et par extension – si on s'accorde pas sur un autre modèle – des programmes, tutoriels et autres.

Je voyais quelque chose d'un peu plus simple qu'une appli complète, mais certes. C'est pas des fichiers joints, mais comme le code de Filoji traite un peu de tous les fichiers uploadés je pense que le sujet va revenir vite et/ou que le code va être dupliqué à ce moment-là, donc je l'évoque dès maintenant.

> Si tu as une propal qui prends en compte tout les cas de figure, tout en étant assez permissive mais pas trop chiante à maintenir, vas-y hein… x) Disons que pour ce qui est des programmes/tutoriels/etc je pense qu'il est élégant d'ajouter des propriétés dans le modèle pour laisser de latitude à l'utilisateur plutôt que de tout faire en automatique. D'ailleurs on est tombés sur ça au moins deux fois : pour la sélection de l'image de présentation d'un programme et pour les fichiers cachés par défaut. J'ai eu un peu l'impression que ça te dérangeait notamment quand tu as dit ça, ce qui ne me paraît pas vraiment naturel. > Pour l'image, je pensais chercher les images en PJ du top comment. --- > Dans tous les cas il faudra bien que les versions successives arrivent dans les commentaires. Je trouverai ça dommage d'en perdre le fil. Ça pose quand même un léger problème de stockage (ce que je n'ai pas réalisé tout de suite). Les plus gros projets sont aussi ceux qui sont modifiés le plus, et un add-in Prizm ça fait vite 2 Mo par fichier par version. Personnellement ça ne me paraît pas abusif d'archiver ainsi les versions de programmes, mais pour les commentaires génériques je suis convaincu qu'il faut des limites plus strictes. Par exemple les logiciels actuels font jusqu'à plus de 50 Mo (ClassPad Manager). Tu peux clairement pas te permettre de mettre cette limite partout dans les commentaires d'un topic random, ça poserait autant de problèmes d'abus sur le stockage que sur la taille des requêtes et la bande passante du serveur. > Là je suis pas d'accord. Pourquoi un commentaire construit sur un topic présentant l'avancement d'un projet imposant ne pourrait pas bénéficiers d'autant de place qu'un programme ? Bien sûr, quand l'auteur d'un projet poste des updates sur ce projet, pas de raison de se priver. Mais ce n'est pas le commentaire random d'un invité qui poste sur un topic qu'il n'a jamais lu, cas qui dans ta proposition autorise les mêmes limites. Mon intuition est d'autoriser un stockage conséquent pour le *topic* au lieu de ses commentaires, ce qui permet à l'auteur de faire ce qu'il veut sans pour autant ouvrir la porte à toutes les dérives. Pour ce qui est des archives d'anciens post principaux, on les comptabiliserait alors simplement dans les limites du topic/programme sans appliquer les limites plus restrictives que je propose sur les commentaires quelconques. En outre, cela résoud le risque que j'avais évoqué que les versions soient publiées juste en commentaire car les gros fichiers ne peuvent être ajoutés que si un nouveau post principal est écrit. > Si on fait ça on va repartir dans le mode v42, postant plusieurs messages pour héberger plusieurs images. Je décèle une pente glissante ici, tu sais bien que je considère cette limite de la v42 comme un problème et que je ne proposerais pas un système qui nous oblige à faire ça. > J'aurai tendance à dire qu'on ne devrait pas limiter les PJ à priori mais à postériori (avec la page d'admin qui va bien). Qu'on autorise ou non les PJ dans les MP d'ailleurs. Je garde bien ça à l'oeil, mais outre les enjeux de PJ dans les MP qui posent des questions de confidentialité, il reste le problème de la bande passante et de la réactivité du serveur qui peut en prendre un coup. > Ok, mais ça nécessite une app de stockage de fichiers, donc c'est un peu hors-sujet, ici on traite des pièces-jointes des commentaires, et par extension – si on s'accorde pas sur un autre modèle – des programmes, tutoriels et autres. Je voyais quelque chose d'un peu plus simple qu'une appli complète, mais certes. C'est pas des fichiers joints, mais comme le code de Filoji traite un peu de tous les fichiers uploadés je pense que le sujet va revenir vite et/ou que le code va être dupliqué à ce moment-là, donc je l'évoque dès maintenant.
Owner

Disons que pour ce qui est des programmes/tutoriels/etc je pense qu'il est élégant d'ajouter des propriétés dans le modèle pour laisser de latitude à l'utilisateur plutôt que de tout faire en automatique. D'ailleurs on est tombés sur ça au moins deux fois : pour la sélection de l'image de présentation d'un programme et pour les fichiers cachés par défaut.

Ça ne me dérange pas de stocker ça dans les métadonnées du programme, mais ça ajoute de la spécificité aux programmes/tutos, alors qu'en soit les topics fonctionnent pareil, au moins pour les news.

Mon intuition est d'autoriser un stockage conséquent pour le topic au lieu de ses commentaires, ce qui permet à l'auteur de faire ce qu'il veut sans pour autant ouvrir la porte à toutes les dérives.

Empêchant d'autres membres de faire des retours complets sur un autre projet… Empêchant aussi l'auteur d'un topic de 50 pages et 40 updates d'ajouter encore plus de contenu.

Je serais plus partant pour une limitation par type de membre plus que par contexte. Drastique pour les invités, un peu plus légère pour les membres, assez large pour les membres+, et illimité pour le reste.

Sachant que quoi qu'il arrive la limite pête en postant plusieurs messages… Chose qui arrivera si les limites ne couvrent pas les usages légitimes. Cf l'addendum de ce message.

car les gros fichiers ne peuvent être ajoutés que si un nouveau post principal est écrit.

Et écrire un nouveau post principal, c'est écrire un nouveau commentaire. Ou alors le modèle MainPost <> Thread <> TopComment n'est pas adapté. Ce que je trouve dommage parce qu'il répond à beaucoup de problèmes d'un coup, en particulier l'historique des conversations.

mais outre les enjeux de PJ dans les MP qui posent des questions de confidentialité

On peut modérer les PJ sans en avoir le contenu. Le poids, la quantité et la fréquence peut être suffisant. À voir, même si j'ai pas d'avis sur autoriser ou non les PJ dans les MP.

De toute façon les MP n'ont pas pour vocation d'être 100% confidentiels. C'est un outil mis à disposition pour échanger rapidement entre deux membres. Pour le reste, c'est à eux de se mettre d'accord sur un moyen d'échange approprié.

Je voyais quelque chose d'un peu plus simple qu'une appli complète, mais certes. C'est pas des fichiers joints, mais comme le code de Filoji traite un peu de tous les fichiers uploadés je pense que le sujet va revenir vite et/ou que le code va être dupliqué à ce moment-là, donc je l'évoque dès maintenant.

La classe Attachment n'est peut-être pas adaptée dans ce cas. On peut la renommer en File si tu veux. Mais bon, je vois pas comment tu veux gérer l'hébergement des fichiers admin sur le même modèle que le reste.


Je pense qu'un bon panel admin de gestion des fichiers pour modérer les abus sera plus efficace que d'essayer de les limiter à priori, avec les conséquences que ça peut avoir quand on aura des utilisateurs cherchant à les contourner. On peut leurrer un programme, un admin c'est plus compliqué. 😉

De manière générale le stockage des PJ va obligatoirement bouffer par mal de place. Aujourd'hui on ne le voit pas parce que 95% des images sont stockées ailleurs. J'espère qu'à terme on n'arrivera plus à tout mettre sur le VPS, car l'inverse voudrait dire restreindre des usages légitimes. Et ça ne me fait pas du tout peur d'envisager un moyen de stockage dédié (et adapté) aux fichiers du site.

> Disons que pour ce qui est des programmes/tutoriels/etc je pense qu'il est élégant d'ajouter des propriétés dans le modèle pour laisser de latitude à l'utilisateur plutôt que de tout faire en automatique. D'ailleurs on est tombés sur ça au moins deux fois : pour la sélection de l'image de présentation d'un programme et pour les fichiers cachés par défaut. Ça ne me dérange pas de stocker ça dans les métadonnées du programme, mais ça ajoute de la spécificité aux programmes/tutos, alors qu'en soit les topics fonctionnent pareil, au moins pour les news. > Mon intuition est d'autoriser un stockage conséquent pour le topic au lieu de ses commentaires, ce qui permet à l'auteur de faire ce qu'il veut sans pour autant ouvrir la porte à toutes les dérives. Empêchant d'autres membres de faire des retours complets sur un autre projet… Empêchant aussi l'auteur d'un topic de 50 pages et 40 updates d'ajouter encore plus de contenu. Je serais plus partant pour une limitation par type de membre plus que par contexte. Drastique pour les invités, un peu plus légère pour les membres, assez large pour les membres+, et illimité pour le reste. Sachant que quoi qu'il arrive la limite pête en postant plusieurs messages… Chose qui arrivera si les limites ne couvrent pas les usages légitimes. Cf l'addendum de ce message. > car les gros fichiers ne peuvent être ajoutés que si un nouveau post principal est écrit. Et écrire un nouveau post principal, c'est écrire un nouveau commentaire. Ou alors le modèle `MainPost <> Thread <> TopComment` n'est pas adapté. Ce que je trouve dommage parce qu'il répond à beaucoup de problèmes d'un coup, en particulier l'historique des conversations. > mais outre les enjeux de PJ dans les MP qui posent des questions de confidentialité On peut modérer les PJ sans en avoir le contenu. Le poids, la quantité et la fréquence peut être suffisant. À voir, même si j'ai pas d'avis sur autoriser ou non les PJ dans les MP. De toute façon les MP n'ont pas pour vocation d'être 100% confidentiels. C'est un outil mis à disposition pour échanger rapidement entre deux membres. Pour le reste, c'est à eux de se mettre d'accord sur un moyen d'échange approprié. > Je voyais quelque chose d'un peu plus simple qu'une appli complète, mais certes. C'est pas des fichiers joints, mais comme le code de Filoji traite un peu de tous les fichiers uploadés je pense que le sujet va revenir vite et/ou que le code va être dupliqué à ce moment-là, donc je l'évoque dès maintenant. La classe `Attachment` n'est peut-être pas adaptée dans ce cas. On peut la renommer en `File` si tu veux. Mais bon, je vois pas comment tu veux gérer l'hébergement des fichiers admin sur le même modèle que le reste. --- Je pense qu'un bon panel admin de gestion des fichiers pour modérer les abus sera plus efficace que d'essayer de les limiter à priori, avec les conséquences que ça peut avoir quand on aura des utilisateurs cherchant à les contourner. On peut leurrer un programme, un admin c'est plus compliqué. :wink: De manière générale le stockage des PJ va obligatoirement bouffer par mal de place. Aujourd'hui on ne le voit pas parce que 95% des images sont stockées ailleurs. J'espère qu'à terme on n'arrivera plus à tout mettre sur le VPS, car l'inverse voudrait dire restreindre des usages légitimes. Et ça ne me fait pas du tout peur d'envisager un moyen de stockage dédié (et adapté) aux fichiers du site.
Owner

Hmm d'accord, je pense que je peux me ranger sur l'usage d'un système identique pour la modération des contenus et les commentaires. Avec les points importants suivants :

  • Limites par membre plutôt que par contexte, avec la possibilité pour les admins de remonter manuellement les seuils (évite les abus)
  • Une seule méthode d'inclusion de fichiers joints avec vérification d'extension et application de limites est utilisée pour les commentaires et les contenus

Je souhaiterais seulement revenir sur le traitement qui est fait de ces fichiers. Je pense qu'un peu de flexibilité serait bienvenue pour accomplir les tâches "élaborées" que les contenus réservent au fichier joints. En particulier...

  • Pouvoir définir une image de présentation [Program]
  • Pouvoir masquer des fichiers joints par défaut, pour utiliser dans la description [Program] ou le texte [Tutorial] (évidemment les admins peuvent tout voir)
  • Pouvoir ordonner les fichiers en téléchargement [Program]
  • Pouvoir définir un fichier principal dans un tutoriel (sous-entendu un PDF pour lecture hors ligne) [Tutorial]
  • ... et probablement d'autres.

Les détails seraient certainement à fixer ; ici je défends seulement l'attitude d'ajouter des propriétés aux Attachment ou aux MainPost qui les référencent pour gérer ces fonctionnalités-là en donnant le contrôle à l'utilisateur, plutôt que de partir du principe qu'une preview des fichiers dont le nom laisse entendre que c'est des images suffira.

Hmm d'accord, je pense que je peux me ranger sur l'usage d'un système identique pour la modération des contenus et les commentaires. Avec les points importants suivants : * Limites par membre plutôt que par contexte, avec la possibilité pour les admins de remonter manuellement les seuils (évite les abus) * Une seule méthode d'inclusion de fichiers joints avec vérification d'extension et application de limites est utilisée pour les commentaires et les contenus Je souhaiterais seulement revenir sur le traitement qui est fait de ces fichiers. Je pense qu'un peu de flexibilité serait bienvenue pour accomplir les tâches "élaborées" que les contenus réservent au fichier joints. En particulier... * Pouvoir définir une image de présentation [Program] * Pouvoir masquer des fichiers joints par défaut, pour utiliser dans la description [Program] ou le texte [Tutorial] (évidemment les admins peuvent tout voir) * Pouvoir ordonner les fichiers en téléchargement [Program] * Pouvoir définir un fichier principal dans un tutoriel (sous-entendu un PDF pour lecture hors ligne) [Tutorial] * ... et probablement d'autres. Les détails seraient certainement à fixer ; ici je défends seulement l'attitude d'ajouter des propriétés aux Attachment ou aux MainPost qui les référencent pour gérer ces fonctionnalités-là en donnant le contrôle à l'utilisateur, plutôt que de partir du principe qu'une preview des fichiers dont le nom laisse entendre que c'est des images suffira.
Owner

Je te rejoins, d'où la proposition de mon modèle (ordre + hidden) qui répond parfaitement à tout ça.

  • Pouvoir définir une image de présentation [Program] → on prend la première image
  • Pouvoir masquer des fichiers joints par défaut → hidden, même si je ne vois pas de cas légitime où on ne voudrait pas de la table des figures
  • Pouvoir ordonner les fichiers en téléchargement → on utilise l'ordre des PJ

Le cas du tuto, j'aurais tendance à générer le PDF nous-même. Sinon c'est relou pour l'utilisateur d'avoir à mettre à jour son tuto plus le PDF si il corrige une coquille. Sans parler de l'uniformité des templates, mais ça c'est annexe.

Les autres cas de figure, on les gère aussi : la banque de sprites ? On met dans une galerie les fichiers images, on affiche en bas les .xcf et les liens de téléchargement. Tu veux pouvoir mettre des images dans une news et définir une image principale pour le partage sur les réseaux sociaux ? Tu prends la première image en PJ. Etc. Tu veux pouvoir vérifier qu'il n'y a pas eu trop d'abus ces derniers temps ? /admin/fichiers, tu affiche un tableau avec l'origine, l'auteur, la date et la taille des Attachments, de quoi les supprimer facilement si besoin.

Non clairement je trouve ce système fiable, robuste, et suffisament évolutif pour qu'il soit implémenté.


Je suis prêt à accepter le flag hidden même si je ne vois pas pourquoi on voudrait cacher des fichiers de la table des figures.

Je te rejoins, d'où la proposition de mon modèle (ordre + hidden) qui répond parfaitement à tout ça. - Pouvoir définir une image de présentation [Program] → on prend la première image - Pouvoir masquer des fichiers joints par défaut → `hidden`, même si je ne vois pas de cas légitime où on ne voudrait pas de la table des figures - Pouvoir ordonner les fichiers en téléchargement → on utilise l'ordre des PJ Le cas du tuto, j'aurais tendance à générer le PDF nous-même. Sinon c'est relou pour l'utilisateur d'avoir à mettre à jour son tuto plus le PDF si il corrige une coquille. Sans parler de l'uniformité des templates, mais ça c'est annexe. Les autres cas de figure, on les gère aussi : la banque de sprites ? On met dans une galerie les fichiers images, on affiche en bas les `.xcf` et les liens de téléchargement. Tu veux pouvoir mettre des images dans une news et définir une image principale pour le partage sur les réseaux sociaux ? Tu prends la première image en PJ. Etc. Tu veux pouvoir vérifier qu'il n'y a pas eu trop d'abus ces derniers temps ? `/admin/fichiers`, tu affiche un tableau avec l'origine, l'auteur, la date et la taille des `Attachments`, de quoi les supprimer facilement si besoin. Non clairement je trouve ce système fiable, robuste, et suffisament évolutif pour qu'il soit implémenté. --- Je suis prêt à accepter le flag `hidden` même si je ne vois pas pourquoi on voudrait cacher des fichiers de la table des figures.
Owner

On va y arriver !

Le cas du tuto, j'aurais tendance à générer le PDF nous-même.

Euh... je suis pas chaud pour avoir LaTeX sur le VPS surtout avec tous les modules classiques qui nécessite -shell-escape (eg. minted). Oublie pas qu'on avait ça dans le viseur.


Et... tout dans l'usage des fichiers pour les MainPost est plus subtil que ce que tu présentes.

la banque de sprites ? On met dans une galerie les fichiers images, on affiche en bas les .xcf et les liens de téléchargement.

Tout le monde n'utilise pas Gimp/Photoshop, les PNG sont souvent les images de travail. Donc tu traites pas pareil les images sources PNG et les images sources XCF - problème de sémantique. Tu es incapable de distinguer un PNG de preview où je présente une map d'exemple du PNG de mon tileset qui est le véritable asset. C'est bâclé !

Tu veux pouvoir mettre des images dans une news et définir une image principale pour le partage sur les réseaux sociaux ? Tu prends la première image en PJ.

Justement non c'est ce raisonnement qui est le problème ! Non, si tu veux mettre une image de présentation d'une news qui part sur les réseaux sociaux, tu mets un attribut dans Topic pour définir quel fichier joint est cette image. Et je te rappelle qu'il n'y a pas d'ordre sur ces fichiers dans le modèle que tu défends ! (Et pas non plus dans ce que je propose ci-dessous)

Pourquoi vouloir hacker sans cesse avec des cas particuliers, des traitements par extension pour la visualisation et des premiers touts ? Puisque tu laisses l'utilisateur uploader les fichiers, laisse-lui dire comment ces fichiers doivent être traités !


Proposition pour le gestion des MainPost, incluant les photos de présentation/réseaux sociaux, l'ordre des fichiers à télécharger, les PDF principaux de tutoriels, etc :

  1. On ajoute les fichiers dans le top comment comme on le ferait pour n'importe quel commentaire. Il n'y a pas d'ordre, pas de métadonnées, pas de propriétés.
  2. Dans chaque MainPost on référence les fichiers joints qui ont un rôle particulier.
    • Dans Program, l'image de présentation et les 3/5/whatever fichiers à télécharger (on a donc 3/5/whatever combo box dans laquelle on peut choisir parmi les fichiers uploadés - zéro trick CSS, zéro JS)
    • Dans Topic, l'image de présentation qui va aussi sur les réseaux sociaux
    • Dans Tutorial, le PDF LaTeX précompilé aux petits oignons
    • Dans les assets graphiques, le ou les 3/5/whatever fichiers qui ne sont pas des preview ou des showcase de ce que l'asset peut faire
On va y arriver ! > Le cas du tuto, j'aurais tendance à générer le PDF nous-même. Euh... je suis pas chaud pour avoir LaTeX sur le VPS surtout avec tous les modules classiques qui nécessite `-shell-escape` (eg. `minted`). Oublie pas qu'on avait ça dans le viseur. --- Et... tout dans l'usage des fichiers pour les MainPost est plus subtil que ce que tu présentes. > la banque de sprites ? On met dans une galerie les fichiers images, on affiche en bas les .xcf et les liens de téléchargement. Tout le monde n'utilise pas Gimp/Photoshop, les PNG sont souvent les images de travail. Donc tu traites pas pareil les images sources PNG et les images sources XCF - problème de sémantique. Tu es incapable de distinguer un PNG de preview où je présente une map d'exemple du PNG de mon tileset qui est le véritable asset. C'est bâclé ! > Tu veux pouvoir mettre des images dans une news et définir une image principale pour le partage sur les réseaux sociaux ? Tu prends la première image en PJ. Justement non c'est ce raisonnement qui est le problème ! Non, si tu veux mettre une image de présentation d'une news qui part sur les réseaux sociaux, tu mets un attribut dans Topic pour définir quel fichier joint est cette image. Et je te rappelle qu'il n'y a pas d'ordre sur ces fichiers dans le modèle que tu défends ! (Et pas non plus dans ce que je propose ci-dessous) Pourquoi vouloir hacker sans cesse avec des cas particuliers, des traitements par extension pour la visualisation et des premiers touts ? Puisque tu laisses l'utilisateur uploader les fichiers, laisse-lui dire comment ces fichiers doivent être traités ! --- Proposition pour le gestion des MainPost, incluant les photos de présentation/réseaux sociaux, l'ordre des fichiers à télécharger, les PDF principaux de tutoriels, etc : 1. On ajoute les fichiers dans le top comment comme on le ferait pour n'importe quel commentaire. Il n'y a pas d'ordre, pas de métadonnées, pas de propriétés. 2. Dans chaque MainPost on référence les fichiers joints qui ont un rôle particulier. * Dans Program, l'image de présentation et les 3/5/whatever fichiers à télécharger (on a donc 3/5/whatever combo box dans laquelle on peut choisir parmi les fichiers uploadés - zéro trick CSS, zéro JS) * Dans Topic, l'image de présentation qui va aussi sur les réseaux sociaux * Dans Tutorial, le PDF LaTeX précompilé aux petits oignons * Dans les assets graphiques, le ou les 3/5/whatever fichiers qui ne sont pas des preview ou des showcase de ce que l'asset peut faire
Owner

Va pour ton modèle. Je note que tu oublie l'idée d'ordonner les téléchargements, très bien.

Pour le reste (faire une galerie auto par exemple), on peut se démerder.

Et je viens de me dire. Si on proxifie pas les reqûetes d'une manière ou d'une autre, on ne peut pas tracer le nombre de téléchargements sans parser les logs de connexion. À la rigeur on peut ajouter une route qui compte les téléchargements du fichier et retourne une 302 vers le fichier statique. Ça ne comptabilisera que les téléchargements via le lien de redirection, mais c'est déjà ça.

Va pour ton modèle. Je note que tu oublie l'idée d'ordonner les téléchargements, très bien. Pour le reste (faire une galerie auto par exemple), on peut se démerder. Et je viens de me dire. Si on proxifie pas les reqûetes d'une manière ou d'une autre, on ne peut pas tracer le nombre de téléchargements sans parser les logs de connexion. À la rigeur on peut ajouter une route qui compte les téléchargements du fichier et retourne une 302 vers le fichier statique. Ça ne comptabilisera que les téléchargements via le lien de redirection, mais c'est déjà ça.
Owner

Merci de m'avoir rejoint ici. Je pense aussi que c'est plus élégant si on peut éviter l'ordre.

Et je viens de me dire. Si on proxifie pas les reqûetes d'une manière ou d'une autre, on ne peut pas tracer le nombre de téléchargements sans parser les logs de connexion. À la rigeur on peut ajouter une route qui compte les téléchargements du fichier et retourne une 302 vers le fichier statique. Ça ne comptabilisera que les téléchargements via le lien de redirection, mais c'est déjà ça.

Hmm j'ai cherché un moyen de faire ça avec Nginx, je pense avoir trouvé un bon compromis. Ce qu'on peut faire c'est utiliser le module mirror pour émettre une sorte de requête miroir purement interne après avoir envoyé le fichier au client. Donc le client obtient le fichier sans le surcoût de la redirection et sans le surcoût du passage à Flask.

location /static/programs {
    alias /home/pc-dev/data/programs;
    mirror /count-downloads/programs;
}

location /count-downloads/programs {
    # Envoyer à Flask, qui écoute sur @application
    try_files @fake @application;
}

Et ensuite dans Flask :

@app.route("/count-downloads/programs/<file>")
def count_download(file):
    # Ajouter 1 au compteur de téléchargements de <file>

Les avantages donc c'est que Nginx sert le fichier de façon transparente pour l'utilisateur sans redirection, avant d'émettre la requête miroir ; et il ignore la réponse à la requête miroir, donc la connexion HTTP n'est pas maintenue.

Merci de m'avoir rejoint ici. Je pense aussi que c'est plus élégant si on peut éviter l'ordre. > Et je viens de me dire. Si on proxifie pas les reqûetes d'une manière ou d'une autre, on ne peut pas tracer le nombre de téléchargements sans parser les logs de connexion. À la rigeur on peut ajouter une route qui compte les téléchargements du fichier et retourne une 302 vers le fichier statique. Ça ne comptabilisera que les téléchargements via le lien de redirection, mais c'est déjà ça. Hmm j'ai cherché un moyen de faire ça avec Nginx, je pense avoir trouvé un bon compromis. Ce qu'on peut faire c'est utiliser le [module `mirror`](https://nginx.org/en/docs/http/ngx_http_mirror_module.html) pour émettre une sorte de requête miroir purement interne *après* avoir envoyé le fichier au client. Donc le client obtient le fichier sans le surcoût de la redirection et sans le surcoût du passage à Flask. ``` location /static/programs { alias /home/pc-dev/data/programs; mirror /count-downloads/programs; } location /count-downloads/programs { # Envoyer à Flask, qui écoute sur @application try_files @fake @application; } ``` Et ensuite dans Flask : ``` @app.route("/count-downloads/programs/<file>") def count_download(file): # Ajouter 1 au compteur de téléchargements de <file> ``` Les avantages donc c'est que Nginx sert le fichier de façon transparente pour l'utilisateur sans redirection, avant d'émettre la requête miroir ; et il *ignore* la réponse à la requête miroir, donc la connexion HTTP n'est pas maintenue.
Darks closed this pull request 2020-08-01 21:47:33 +02:00
Sign in to join this conversation.
No description provided.