🌍
Français
Oups! (Ça dort ici, les idées sont en panne), up... Up.... UP... UP!.. UP!. UP! UP!! UP!!!
On se réveille.
Dans la table `#_categories`
la colonne `visible`, ENUM( 'true', 'false' ), NOT NULL, DEFAULT 'true'
ne représente pas sa visibilité mais son verrouillage.
Faut-il une vraie colonne `visible` comme le sous-entend ceci?
Ce qui permettrait de faire de l'upload sur cette catégorie sans pour autant,
voir les uploads validés apparaître dans Spéciales + Dernières images...
Alors?
Pourquoi c'est lié aux catégories virtuelles? Effectivement, pas uniquement à ces catégories. Mais demain avec XML Service, ça serait très sympa, très très sympa... Non?
Cela n'a rien à voir avec "agreed_xml_service" qui dit cette catégorie est éligible ou non; mais cela permettra de préparer les listes à livrer via XML Service sans que cette catégorie s'affiche dans la galerie même en étant publique et qu'on puisse l'enrichir indépendament des catégories existantes par exemple.
Ce point aurait pu être dans le sujet services web c'est une section commune d'arbo différentes comme dirait rub. 8-)
Votre avis?
VDigital a écrit:
Assez plaisanté : d'autres idées, sur les catégories virtuelles?
Au début, je voulais utiliser la même catégorie virtuelle à deux catégories virtuels (pas possible actuellement à cause des rank, uppercat)... Pourquoi? Pour faire des arbo différentes mais avec section communu par groupes...
Est-ce une demande d'évolution resonnaible? ou ca n'interresse que moi?
VDigital a écrit:
rub a écrit:
3eme Fichier identiques:
Si 2 fichiers sont identiques (pas forcement le même nom), quelque soit le système de stokage, c'est qu'ils ont le même md5...
M3=> donc avec une gestion de stockage basée sur le md5, il est facile de savoir pour le fichier à charger, il y a déjà un fichier identique.... il faut refuser le fichierSuperflu !! A mon avis.
Je trouve pas... c'est peut-être moi, j'aime pas les doublons....
Mais bon, le md5, sert à la base à la base à calculer un check-sum pour déterminer l'unicté d'un fichier... c'est dommage de sans servir pour les noms de répertoires et pas pour l'unicité... mais bon, ce n'est que mon avis...
rub a écrit:
3eme Fichier identiques:
Si 2 fichiers sont identiques (pas forcement le même nom), quelque soit le système de stokage, c'est qu'ils ont le même md5...
M3=> donc avec une gestion de stockage basée sur le md5, il est facile de savoir pour le fichier à charger, il y a déjà un fichier identique.... il faut refuser le fichier
Superflu !! A mon avis.
Rappel:
MBt a écrit:
rub a écrit:
En résumé:
o pour les fichiers physiques identiques (ayant peut-être un nom différent) un check-sum-md5 du fichier physique (même si gourmant en ressource)Aïe ça sent le doublon. Si un de tes potes veux te fourguer une photo que t'as déjà met lui une claque... :-P
VDigital a écrit:
MBt a écrit:
rub a écrit:
o pour les noms ajout d'une chaine séquencés ou par clef...
Là par contre ça me parait cohérent. J'ai tendance à nommer les photos avec le nom des personnes qui sont représentées et il peut facilement y avoir des doublons.
Oui, c'est vrai mais j'ai tendance à préférer la solution MD5 ( microseconde & filename ).
Dans ce que j'avais écrit ce n'était pas 2 solutions, mais une seule...
J'avais aussi mal lu ce que qu'avait dit z0rglub...
Brefn j'ai l'impression qu'on mélange 2 sujets différents pour l'upload.
Mais avant, il faut préciser que ca concerne les catagéories physiques ou virtuelles (virtuelle uoloadable est encore un autre problème).
Donc,
1er pbStockage de données:
Ne pas avoir un million d'images dans un répertoire
M1=> le coup des sous-répertoires construit avec le hash md5 parfait (nombre de niveau à paramètrer)
2eme pb Unicité des données:
Rub et MBt (lol) veulent mettre chacun une photo pwg_is_better.jpg, leur hash est différent mais commence par les même caractères (pas de bol mais c'est possible comme de gagner au loto), il faut donc avoir un nom unique
M2=> Contenation d'un numéro de séquence gloable au répertoire de base ou une séquence pour chaque sous-répertoires ou bien tout simplement le hash... les microsecondes, j'aime pas car si rub et mbt charge un fichie de même nom et si le hash commence pareil et il sont synchro, on a doublons (1 chance sur 1 milliard mais bon, c'est comme la chauve souris de bigard)... Ensuite pour un meilleur "apercu" de l'updload, la on peut ajouter le nom, la date, l'heure qui ne permettent pas l'unicité mais qui rende le nom du fichier compréhensible..
3eme Fichier identiques:
Si 2 fichiers sont identiques (pas forcement le même nom), quelque soit le système de stokage, c'est qu'ils ont le même md5...
M3=> donc avec une gestion de stockage basée sur le md5, il est facile de savoir pour le fichier à charger, il y a déjà un fichier identique.... il faut refuser le fichier
Si on appliques les 3 méthodes M1, M2, M3, on aura aucun soucis...
M1 fonctionnerai mais un risque de nom identiques
M2 et M3 seules, temps de réponse pas top...
z0rglub a écrit:
VDigital a écrit:
L'utilisateur appelons-le "rub" veut me charger l'image "01.jpg" sur mon site. Ok?
Deux jours plutard, l'utilisateur appelons-le "MBt" veut me charger son image "01.jpg" sur mon site.
Que fait-on?Excellent, je pensais justement à cela dans ma douche ce matin.
z0rglub a fait un lapsus ce matin, il voulait dire "à ceux-là dans ma douche", "à ceux-là": MBt et rub, bien entendu !!!
8-D
Bravos !!! Bravos pour vos idées...
Assez plaisanté : d'autres idées, sur les catégories virtuelles?
MBt a écrit:
Hey rub,
t'as vu on utilise plus titi et toto dans les exemples mais "rub" et "MBt". C'est cool la célébrité! Vive la web-réalité...
Ca, c'est sur c'est cool! ;-)
MBt a écrit:
rub a écrit:
o pour les noms ajout d'une chaine séquencés ou par clef...
Là par contre ça me parait cohérent. J'ai tendance à nommer les photos avec le nom des personnes qui sont représentées et il peut facilement y avoir des doublons.
Oui, c'est vrai mais j'ai tendance à préférer la solution MD5 ( microseconde & filename ).
Parce qu'il devient difficile de deviner comment s'appelle le répertoire suivant.
Je considère donc le "hic" comme ayant au moins une solution et c'est tant mieux.
Bien vu. Merci.
D'autres idées, sur les catégories virtuelles?
Hey rub,
t'as vu on utilise plus titi et toto dans les exemples mais "rub" et "MBt". C'est cool la célébrité! Vive la web-réalité...
VDigital a écrit:
Pas vexé, j'espère?
En aucune manière, rassure toi...
Un: si une fonctionnalité existe c'est certainement qu'elle a une utilité,
Deux: ce n'est pas moi qui n'ai qu'une semaine d'expérience qui vais remettre en question un projet mature de plus de 4 ans (si je ne me trompe pas dans les dates),
Trois: si je commence à me vexer parce qu'une personne donne son avis sur un forum autant que j'arrête de discuter, et comme ce n'est pas mon genre de me taire... ;o)
rub a écrit:
En résumé:
o pour les fichiers physiques identiques (ayant peut-être un nom différent) un check-sum-md5 du fichier physique (même si gourmant en ressource)
Aïe ça sent le doublon. Si un de tes potes veux te fourguer une photo que t'as déjà met lui une claque... :-P
rub a écrit:
o pour les noms ajout d'une chaine séquencés ou par clef...
Là par contre ça me parait cohérent. J'ai tendance à nommer les photos avec le nom des personnes qui sont représentées et il peut facilement y avoir des doublons.
MBt
Vous voulez faire la check sum sur le nom de fichier???
Ou j'ai mal saisi!
Pour moi et reprenant ce que vous avez dit, il faut faire le checksummd5 sur le fichier physique, ca permet d'eviter de mettre 2 images identiques.
Pour les noms de fichier en double, on peut mettre en place une "séquence" par catégories pour avoir le nom unique, ou une clef uniquement pour le RSS,notification par mail.
Cette chaine étant ajoutées au nom de fichier original (préfixe ou suffixe) et pourquoi pas ajouté aussi les identifiants du user (name)... Bref...
Cette chaine peut être ajouté uniquement sur doublons.
Sinon, le plus simple c'est de refuser les noms identiques.
Sinon pour les micro secondes par trop pour, on peut arriver à des doublons...
En résumé:
o pour les fichiers physiques identiques (ayant peut-être un nom différent) un check-sum-md5 du fichier physique (même si gourmant en ressource)
o pour les noms ajout d'une chaine séquencés ou par clef...
Oui. Microsecondes concaténées au nom, un MD5 dessus et j'ai mes trois sous-répertoires.
Si tu fais (toi ou chris), on est quasiment obligés de sortir le répertoire d'upload des visiteurs de /galleries/.
Ou alors, Synchro exclus de lui-même le répertoire d'upload.
Je ne sais pas ce qui sera le plus simple et le plus performant.
VDigital a écrit:
L'utilisateur appelons-le "rub" veut me charger l'image "01.jpg" sur mon site. Ok?
Deux jours plutard, l'utilisateur appelons-le "MBt" veut me charger son image "01.jpg" sur mon site.
Que fait-on?
Excellent, je pensais justement à cela dans ma douche ce matin.
Je me dit qu'au lieu de faire le hash MD5 de "toto.jpg", il faut faire le hash de la concaténation de "toto.jgp" avec le nombre de microsecondes depuis l'epoque unix par exemple, ou une chaîne aléatoire sur 50 caractères (genre get_key dans PWG).
On avance bien sur le sujet visiblement...
Il est temps pour moi d'expliquer le vrai "hic" de l'upload (virtuelles bien sûr avant tout mais réelles aussi).
Le hash MD5 de "toto.jpg" pour créer le rep adhoc et soulager le FS, j'adore.
D'autant qu'il renforce le niveau de sécurité.
Mais il ne règle pas mon 'hic'.
L'utilisateur appelons-le "rub" veut me charger l'image "01.jpg" sur mon site. Ok?
Deux jours plutard, l'utilisateur appelons-le "MBt" veut me charger son image "01.jpg" sur mon site.
Que fait-on?
Je ne veux pas décevoir "rub", ni décevoir "MBt" of course.
Merci de votre éclairage.
Le principe "administrateur associe une catégorie physique à une catégorie virtuelle pour l'upload" me semble géniale. Dans cette idée, et pour simplifier la maintenance du site, l'admin sera tenté de mettre une seule catégorie physique d'upload. Et là je dit "attention" : si une galerie abuse du système, il va se retrouver avec 50,000 fichiers dans le même répertoire et ce sera le drame en terme de performances. Aucun filesystem n'est optimisé pour gérer autant de fichiers par répertoire.
Il faudrait alors prévoir un système comme sur free.fr : toto.jpg va dans upload/t/o/t/toto.jpg. Sauf que la plupart des photos uploadées vont s'appeler img_* ce qui déporte le problème à upload/i/m/g, bref, il faut améliorer. Alors je propose upload/9/6/c/toto.jpg car "96c" sont les 3 premiers caractère du hash MD5 en hexadécimal de "toto.jpg". Cela donne :
- toto.jpg => upload/9/6/c/toto.jpg
- tota.jpg => upload/4/5/7/tota.jpg
Mais... je suis en train d'écrire des spécifications techniques pour implémenter un mode communautaire là. Qu'est-ce qui me prend ? Plus sérieusement, je n'ai rien contre le mode communautaire, c'est juste que PhpWebGallery est parti d'un besoin personnel qui ne comprenait pas le mode communautaire. En conséquence l'application n'a pas été conçue pour cela. Maintenant si chrisaga s'attaque à ce gros morceau, je soutiendrai la démarche. Attention quand même à ne pas oublier que ce ne sera pas le mode d'utilisation par défaut à mon avis (enfin, les utilisateurs décideront).
Là où je rejoins complètement MBt, c'est que le mode basique d'utilisation de PhpWebGallery ne comprend pas les catégories virtuelles. Catégories virtuelles = fonctionnalité avancée, pour les utilisateurs avancés. Dire à un débutant qu'il doit créer des catégories virtuelles va à l'encontre de ma vision qui est "les choses simples doivent être faciles à faire et les choses complexes doivent être possibles". (écrit sur la page de présentation de PWG depuis quelques semaines) Alors certes, les catégories virtuelles, c'est un plaisir pour réorganiser sa galerie, mais c'est à l'utilisateur de le découvrir au fur et à mesure.
Rub, ta vision des choses est très bonne mais c'est celle d'un utilisateur avancé. Je pense que les utilisateurs avancés comme toi utilisant PWG sont une cinquantaine, grand maximum. Face à plusieurs milliers qui ne liront que [Administration>Général>Instructions>Démarrage rapide], et c'est normal.
A propos d'un sujet évoqué surtout sur le topic anglais : l'uploadeur choisit la catégorie (physique ou virtuelle) dans laquelle apparaîtra sa photo. C'est donc complémentaire à la vision côté administrateur. Cela n'a d'intérêt que si la photo doit être liée à plusieurs catégories. Sinon, autant aller dans la catégorie de destination et uploader. L'amélioration serait lors de l'upload de proposer un select multiple des catégories dans lesquels l'uploadeur souhaite voir sa photo apparaître. S'en suit une gestion fine des validations côté administration.
La validation automatique, je descendrai dans la rue avec une banderolle pour m'y opposer si c'est nécessaire. Nous ne somme pas dans un système de wiki dans lequel n'importe quoi peut corriger le vandalisme de quelques casseurs. Seul l'admin a ce pouvoir et parfois l'admin, il part en vacances...
Tout cela n'est que le fruit de ma réflexion et un simple avis. Chrisaga est responsable de l'upload et c'est à lui de décider. Cela dit, les propositions énumérées constituent un travail gigantesque, il faudra donc avancer par étapes pour corriger les défauts de conception rapidement.