Pierrick Le Gall a écrit 215 commentaires

CremeCRM est un CRM (Customer Relationship Manager) pas un CMS (Content Management System). Ils l'expliquent d'ailleurs sur leur site : http://www.cremecrm.com/qu-est-ce-qu-un-crm

CRM et CMS, cela n'a tout simplement rien à voir.

Bravo pour cette interview, c'est très intéressant. Je suis le fondateur de Piwigo donc merci d'avoir cité Piwigo parmi les exemples. On devrait reparler de Piwigo dans cette série d'articles, je viens d'en discuter par email avec LeBouquetin.

Par quelques aspects, non chemins se ressemblent. Bon courage à toi dans ton aventure entrepreunariale !

Sauf que lorsque Sun a racheté MySQL, ça n'a rien changé au fonctionnement.
Contrairement au rachat par Oracle

Je persiste à dire que pour le moment, cela ne change rien. MySQL ne devient ni propriétaire ni payant. Certaines nouvelles extensions le sont, mais cela ne concerne pas les besoins de Piwigo ou de tous les utilisateurs d'applications web qui s'hébergent sur du mutualisé.

Il est normal que Monty s'indigne des annonces d'Oracle, son business est maintenant de populariser MariaDB pour ensuite proposer du service autour. On peut dire qu'à son échelle, Monty et MariaDB sont des concurrents à Oracle et son MySQL. Ce qui serait plus intéressant, ce serait des annonces de la part de gros utilisateurs MySQL déclarant vouloir passer à autre chose comme PostgreSQL (ça ça m'étonnerait) ou à MariaDB (ça ça me semble plus probable).

On a juste retiré la liste de choix MySQL/PostgreSQL/SQLite sur le formulaire d'installation.

Il faut bien comprendre que l'expérience de Piwigo sur PostgreSQL était assez frustrante, selon les retours que j'ai pu entendre : on avait droit à un Piwigo buggué et incomplet car très peu de plugins étaient compatibles. Donc à un moment il faut faire un choix et le choix a été de simplifier la vie des développeurs et d'éviter la frustration de ceux qui testaient Piwigo sur PosgreSQL/SQLite.

Piwigo assume ce choix : la totalité de l'équipe de développement a poussé dans ce sens.

Par contre, MySQL a l'inconvénient d'être sous le contrôle d'une boîte
aux méthodes plus que discutables. Ce qui met un tout petit peu sa pérennité
en cause.

Lorsque MySQL AB s'est fait racheté par Sun, je me suis dit que ça ne sentait pas forcément bon. Quelques mois plus tard lorsque Sun s'est fait racheté par Oracle, je me suis dit que ça sentait fortement le roussi pour MySQL. Dans les faits : rien. MySQL continue à être maintenu et à évoluer. MySQL reste un logiciel libre. MySQL reste gratuit. MySQL reste disponible sur toutes les distributions Linux et les hébergeurs mutualisés.

Lorsqu'en pratique Oracle décidera de tuer MySQL, il sera temps pour Piwigo de passer sur autre chose. Et à mon avis, ce sera plutôt sur MariaDB que sur PostgreSQL. MariaDB, c'est le moteur de base de données créé par Monty Widenius le fondateur de MySQL et qui propose un système compatible avec MySQL (la transition est théoriquement sans douleur).

Bref, il faut être un peu pragmatique et voir ce qui se passe dans la réalité et non ce qui pourrait peut-être un jour se passer si on se borne à une vision pessimiste. Il faut être vigilant avec ce qu'Oracle fait de MySQL, mais ne pas anticiper des changements qui n'arriveront peut-être jamais et qui ont de toute façon déjà des solutions toutes trouvées.

je ne vois rien à envier à Picasa [...] Niveau personnalisation vous êtes
carrément devant.

Et oui forcément, Picasa Web Albums (ou Google Photos) n'a manisfestement pas pour objectif d'être "personnalisé", c'est un thème graphique unique pour tout le monde. Au final, rien ne ressemble plus à la galerie de Pierre que celle de Jacques (ah si, il y a celle de Robert qui ressemble beaucoup ;-). On retrouve la même "critique" sur Flickr de Yahoo. Ce n'est pas bien ou mal, c'est une question de positionnement. Google Photos et Flickr s'orientent plutôt "réseaux sociaux photo", donc il est normal d'avoir un thème graphique unique, de sorte à ce que les visiteurs identifient du premier coup d'oeil qu'ils sont bien sur Google Photos.

Vous auriez peut-être intérêt à mettre ces nouveaux apports dans la page de features.
C'est vraiment vendeur et ca couterait pa cher, j'imagine.

De quelles fonctionnalités parles tu exactement ? (je serais ravi de revoir notre page "fonctionnalités" si ça peu améliorer le côté "attractif" ;-)

Pour les related tags, ca ressemble pas mal à ce qui se fait avec
del.icio.us mais c'est super de l'avoir implémenté.

Tout à fait, Delicious est l'un des premiers à l'avoir implémenté. Pour Piwigo, ça date de 2006 environ. Et bizarrement, je ne connais pas d'autres galeries photos qui le font.

Au niveau conception, tags et albums héritent ils du même interface ?

Je ne comprend pas la question :-/

(tagguer automatiquement famille lorsque je taggue fiston ou maman par ex)

Non, on n'a pas ça en 100% automatique. En revanche, dans le gestionnaire par lot, il suffit de filtrer sur le tag "fiston", de sélectionner tout le lot (1 clic) et d'ajouter le tag "famille".

Pour l'hébergement [...] Avez vous une charte ?

Une charte qui dit qu'on ne s'approprie pas vos données personnelles ou qu'on ne monétise pas votre "profil utilisateur" ? Non, ce n'est pas écrit aussi explicitement dans nos "conditions d'utilisation" et autre "politique de confidentialité" (liens en bas de page sur Piwigo.com) mais c'est clairement notre positionnement : l'utilisateur paie parce que le service a un prix et que nous avons décidé de ne pas monétiser les données personnelles de nos utilisateurs. Nous avons choisi ce positionnement car il nous paraît sain. Je ne dis pas que c'est le seul choix acceptable, car l'apparente "gratuité" de certains concurrents est un facteur essentiel pour populariser ce type de service.

Y'a t'il moyen de souscrire un abonnement mensuel plutôt qu'annuel ?

Non. Cela nous coûterait trop cher pour un tarif de cet ordre de grandeur. Cela coûterait en comptabilité et en commissions prélevées par la banque ou par Paypal... Ou alors on augmenterait fortement le prix mensuel de sorte à ce que le 12 x prix mensuel = 2 x prix annuel par exemple. C'est un exemple, mais il faut savoir qu'un paiement de 3.25 euros sur internet, ça fait plaisir aux intermédiaires, mais pas aux vendeurs :-/

Tout d'abord un grand bravo pour cette application. C'est fluide, agréable
et bien léché. Ca fait vraiment pro.

Merci pour ce retour !

Cependant j'aimerais comprendre la différence entre tags et albums.

Les albums sont la structure de la galerie. L'administrateur peut choisir de créer une arborescence plus ou moins complexe selon son besoin. Une photo peut être liée à plusieurs albums.

Les tags sont plutôt destinés à décrire les photos. Une photo peut être liée à plusieurs tags (comme pour les albums). Les tags ne sont volontairement pas hierarchiques. Et surtout le mode de navigation est totalement différent : avec les tags on navigue de manière "transversale" et par combinaison.

Prenons un exemple concret : dans ma galerie j'ai un album pour chaque évènement : anniversaire Kevin, Noël chez tata Paulette, Nouvel an à Rio (ces évènements sont fictifs, toute ressemblance avec la réalité serait totalement fortuite). Dans chacun de ces albums, il y a des photos de mes enfants, donc je taggue avec "Erwann" et/ou "Tiphaine". Grâce à la navigation par tag, je vais pouvoir voir toutes les photos tagguées "Erwann", quelque soit le ou les albums des photos. De plus, et ça c'est génial, je peux voir en 2 clics les photos où figurent à la fois "Erwann" et "Tiphaine". C'est ce qu'on appelle les "tags liés". Il y a un exemple illustré : http://fr.piwigo.org/releases/2.1.0#related_tags

Autres sujet, la géolocalisation. [...] Est-il prévu de s'intégrer avec OSM ?

Ce n'est pas prévu. En tout cas pas à ma connaissance. Je n'ai jamais entendu ou lu que quelqu'un était intéressé par ce projet.

Enfin l'hébergement http://fr.piwigo.com : Y'a t'il moyen de sauvegarder
sa base avec le meta-données associées si l'on décide d'arrêter son abonnement ?

Oui bien sûr, il y a un écran dont c'est l'objectif sur [Administration > Mon compte > Mes données]. C'est l'un des critères différenciateurs de Piwigo.com par rapport à ses concurrents : on ne verrouille pas le client. A tout moment, vous pouvez récupérer un dump de votre base de données et le répertoire qui contient toute les photos. Avec ça, vous pouvez déménager votre galerie Piwigo chez n'importe quel autre hébergeur "classique" sans rien perdre, ni vos données bien sûr, ni vos fonctionnalités ou votre personnalisation.

La question de la performance est vraiment mineure avec notre méthode actuelle d'abstraction à la base de données (c'est à dire de faire du SQL générique). En revanche, si on avait choisi une méthode d'abstraction plus "complète" du type "mapping objet relationnel", ça oui c'est trop coûteux en performances. En tout cas avec les tests réalisés il y a quelques années.

Piwigo disposait en 2.2, comme Perl avec DBI, d'une couche d'abstraction qui permet d'envoyer du SQL qui était ensuite exécuté soit par MySQL soit par PostgreSQL ou encore SQLite.

Le soucis principal, c'est que le SQL n'est pas vraiment générique. Certaines requêtes qui fonctionnent avec MySQL ne fonctionne pas avec PostgreSQL et inversement. Ca devient "compliqué". Or pour faire les choses correctement, il faudrait que tout le monde teste avec plusieurs bases de données : développeurs du "core" et développeurs de "plugins". Or ce n'est clairement pas le cas et c'est compliqué d'aller exiger des contributeurs qu'ils testent sur PostgreSQL dont ils se fichent un peu, pour ne pas dire complètement. L'important se situe davantage au niveau des fonctionnalités et de l'interface utilisateur plutôt que sur le moteur de base de données.

PostgreSQL est un excellent moteur de bases de données mais MySQL est également très bon et a l'énorme avantage d'être disponible absolument partout.

comme drupal ?

sans doute. Je connais moins drupal.

je pense que tu aimerais bien que piwigo se fasse un peu plus hacker [...]

Pas d'inquiétude, on se fait régulièrement hacker. Moins ces derniers temps, mais à une époque c'était "fréquent" (plusieurs failles découvertes par an). Dans ce genre de cas, il y a les gentils qui nous contactent en privé et attendent qu'on sorte le correctif pour publier la faille et les méchants qui publient (parfois à tort) sans nous avertir.

Et je ne suis pas du tout certain que les chercheurs de failles fassent de bons contributeurs. En tout cas, à part un excellent retour d'une personne qui travaille aussi sur Dotclear qui nous a aidé à éviter les CSRF, en général les personnes ne s'intéressent pas à l'application et à ce qu'on peut en faire, ils craquent pour "l'exploit", pour avoir leur pseudo sur un site de sécurité.

Je croyais que les trolls c'était vendredi uniquement. Je regarde mon calendrier, on est pourtant lundi :-)

WP c'est troué

Comme toutes les applications web. C'est attaqué parce que c'est extrêmement populaire donc lorsqu'on trouve une faille sur WordPress, on a des millions de cibles potentielles. (attention troll poilu des cavernes en approche) si tu trouves une faille sur Dotclear, tu divises par 10000 le nombre de cibles potentielles, mais il y en a quand même, des failles(/attention)

c'est en php

C'est en PHP, donc c'est mal ? Je te recommande de ne plus utilisé Wikipedia par exemple... ben oui, l'encyclopédie tourne avec PHP.

ça fait un bon vecteur d'intrusion pour les crackers et autres connards de
script-kiddies quand ce n'est pas à jour :/

Oui, mais si on fait bien les choses normalement, on ne touche pas au core de WordPress (idem Piwigo) et les mises à jour sont très simples (2 clics sur WordPress ou Piwigo)

L'argument du "c'est plein de failles, on va se faire hacker" n'est pas ridicule du tout, mais il faut faire un compromis, sinon on serait obligé de ne faire que du code spécifique pour chaque site pour éviter au maximum ce genre de désagrément.

Je ne dis pas que MySQL est parfait et que les autres devraient faire pareil que lui. Ce n'est vraiment pas mon propos. Je dois vraiment mal m'exprimer si c'est ainsi qu'on me comprend :-/

Les normes SQL, il faut être réaliste : le développeur s'en moque un petit peu. Il consulte la documentation de son SGBD, celui avec lequel il travaille quotidiennement et qui lui importe le plus pour son projet et il adapte les exemples de la documentation pour son besoin de l'instant. Comme beaucoup ici, j'ai appris à l'école toutes ces normes théoriques, qu'on essayait d'appliquer ensuite en TP. Et puis ensuite tu arrives en entreprise, tu as du Oracle partout et exclusivement, tu regardes le modèle et tu te dis "quels guignols, ils ne respectent pas telle ou telle formale...", tu vas voir un développeur expérimenté qui te remet rapidement en place parce qu'ici c'est la vraie vie avec des vraies contraintes de performances et que si on duplique telle ou telle donnée, ça divise par 3 le temps de traitement. C'est juste un exemple, afin de démontrer qu'il y a souvent des écarts entre la théorie et la pratique et que c'est justifiable.

soit tu découples les requêtes SQL du reste du code [...] Si tu me dis, que même
çà à un coût signicatif niveau performances

Je pense que niveau performances, ce serait aussi efficace voire peut-être un poil mieux que ce qu'on fait actuellement. Le soucis, c'est que cela signifie un chantier énorme, pour une finalité pas si énorme que ça.

Tiens je serais curieux de connaître ces optimisations.

On ne peut tout simplement plus utiliser des fonctionnalités spécifiques à MySQL. Il ne faut pas chercher plus loin que cela. Les grosses optimisations, c'est la capacité de faire de l'update en masse par exemple, mais ça ça marche bien avec PostgreSQL. J'explique l'algorithme dans un vieux billet sur mon blog http://le-gall.net/pierrick/en/blog/index.php?post/2007/11/29/108-mysql-bulk-update-with-talend-open-studio

Je me demande ce qui peut entraîner une tel incompatibilité.

Il suffit qu'un thème utilise un REPLACE INTO et hop, il n'est pas compatible avec PostgreSQL ou SQLite. On a des fonctions dans Piwigo pour simplifier ce genre de cas très basique de mise à jour d'une valeur de configuration en base de données, mais tous les développeurs de plugins/thèmes ne les utilise pas.

Disponibilité je comprends, mais libre, gratuit et performant il est loin d'être le seul.

Je me suis mal exprimé. Ce sont ses points forts, il n'est pas le seul à les avoir. Son réel avantage par rapport à PostgreSQL, c'est la disponibilité.

[a propos d'un changement vers MariaDB] Et ça sera une galère monstre
vu comme il semble difficile de gérer postgre actuellement

Non, je ne pense pas. Je serai étonné que les créateurs de MySQL, qui ont créé MariaDB suite au rachat Oracle il me semble, ne fassent pas en sorte que MariaDB soit syntaxiquement compatible avec MySQL (ou alors ce serait stratégiquement un peu bête...)

(on parle quand même d'un SGBD qui a était racheté par Oracle et
qui a connu au moins un fork plus quelques alternatives l'an dernier
juste à cause de ça).

Lors du rachat par Oracle, j'ai cru que les jours de MySQL étaient comptés et je me suis intéressé aux forks de l'époque. Et puis en pratique, rien n'a changé : cela reste libre et gratuit, disponible partout. A ma connaissance, le développement est aussi fermé qu'avant. Bref, pas de changement particulier. Donc pas de quoi s'inquiéter pour le moment.

Perl a DBI

J'ai quelques années de développement Perl derrière moi et je ne vois pas en quoi DBI fait de l'abstraction. DBI prend des requêtes SQL en entrée, donc potentiellement compatible avec un seul SGBD. On a strictement le même système dans Piwigo. Cela ne rend pas le code miraculeusement compatible avec tous les SGBD.

[à propos de la taille du public visé par MediaGoblin] Petite par rapport
à quoi ? Ils cherchent à répondre à un besoin.

Petite par rapport à Piwigo. Ce n'est pas péjoratif. J'espère bien qu'ils cherchent à répondre à un besoin (sinon c'est un peu du temps perdu ;-).

Je répète ce que j'ai dit dans un autre message : il y a 2 niveaux pour les "utilisateurs" de MediaGoblin à mon avis. D'abord ceux qui installent puis ceux qui ouvrent un compte. Ce ne sont a priori pas du tout les même profils. Dans le cas de Piwigo en revanche, celui qui utilise est aussi celui qui installe. Donc le public est assez différent je pense.

est-il plus intéressant d'ajouter des fonctionnalités, ou de porter vers un autre
SGBD ? Personnellement, je me concentrerais sur les features [...]

Quelqu'un de pragmatique. Ca fait plaisir à lire !

Ton cas, c'est du développement spécifique apparemment, tu ne parle pas de développement d'un logiciel "largement" distribué à destination d'un public plutôt novice. La problématique est donc un peu différente.

Quelqu'un s'est déjà demandé pourquoi WordPress n'était compatible qu'avec MySQL ? qu'on ne me dise pas que WordPress c'est nul : WordPress c'est libre, c'est gratuit, c'est correct niveau performances, c'est énormément utilisé et incroyablement populaire. Je n'ai jamais lu de critique du style "WordPress c'est nul, ça tourne pas sur PostgreSQL" (en cherchant on doit en trouver, mais d'emblée je n'en ai jamais lu). Il faut croire que ses autres qualités surpassent ce léger inconvénient. Peut-être que s'ils étaient multiSGBD, ils n'auraient pas pu avoir un "ecosysteme" aussi gigantesque car le "ticket d'entrée" aurait été trop coûteux (faire un plugin compatible multiDB est plus compliqué que juste MySQL).

[sur la facilité à maintenir et étendre Piwigo] Quand changer de SGBDR,
prend un temps pas possible et arrive à faire casser certains thème,
j'ai un doute sur ce dernier point.

Bon bon bon, ça devient de l'attaque un peu gratuite. Je me fais moinser sur mes messages et tu te fais plusser sur les tiens, donc j'ai tendance à croire que quoi je dise, je vais passer soit pour un méchant, soit pour un imbécile, soit pour un incapable :-/

Selon mon expérience, plus tu rajoutes d'intermédiaires, de fonctions qui appellent des classes, elles mêmes dérivées de plusieurs classes, etc.... plus ça devient compliqué à maintenir. Maintenir = corriger un bug. Maintenir != faire évoluer.

J'ai travaillé avec des développeurs qui se prenaient la tête à prévoir que peut-être un jour on voudra faire ceci ou cela avec le code et donc il fallait le prévoir dans l'architecture. Moi je dis stop. Soit on en a besoin tout de suite, soit on ne le prévoit pas et on reste simple dans son architecture. Code simple = code facile à maintenir. C'est d'autant plus important dans un projet libre et ouvert comme Piwigo que le développeur d'une fonctionnalité ne va pas forcément être celui qui va y corriger un bug 3 ans plus tard.

Quant à la capacité d'étendre Piwigo, je parle des thèmes et des plugins. Il y a plus de 200 plugins et plus de 100 thèmes. Pour un CMS "spécifique", c'est plutôt pas mal.

"Changer de SGBD" n'est en aucun cas un besoin récurrent. Et la problématique n'est pas de changer, mais d'être compatible multi-SGBD, ce qui n'est pas du tout la même chose. Si un jour on passe en MariaDB, ce sera bien plus simple que d'être compatible PostgreSQL/SQLite/Firebird/FuturSGBDopensourceAlamode.

Sinon vous avez eu temps de problème de performance pour que ça soit si
primordiale ? Tu nous en parle depuis le début et à toutes les sauces,
c'est une contraintes qui a était si forte que ça ? et dure à tenir ?

Disons que le premier retour que l'on a de la part de ceux qui passent de Coppermine ou Menalto Gallery à Piwigo, c'est la performance : avec Piwigo, quelque soit la quantité de photos, ça va vite. Bon, on a un utilisateur avec plus d'un million de photos qui nous a dit avoir des soucis pour synchroniser. Mais ceux qui sont à plusieurs centaines de milliers sont très contents et nous on dit qu'il n'existait pas d'autre galerie open source qui en soit capable. Je n'ai pas tout testé, je les crois sur parole, d'autant que ça fait plaisir à lire :-)

Oui, tenir la perf c'est difficile à tenir. Désolé d'en parler à toutes les sauces. Je vois tellement d'applications web qui prennent 100% du CPU pendant 2 secondes (grâce à une tripotée de framework MVC et multiple couche d'abstraction) pour afficher une page vide que j'ai à coeur de ne pas reproduire la même chose avec Piwigo.

L'architecture MVC, il y a quelques temps (quelques années) un membre de l'équipe ne jurait que par ça et pour lui c'était évident qu'il fallait adopter ce type d'architecture. Il a fait un prototype tout simple pour voir ce que ça donnait avant de lancer le gros chantier. Résultat sans appel : une catastrophe en terme de performances. La page était entre 5 et 10 fois plus longue à générer côté serveur. Il a tenté ce qu'il pouvait pour améliorer les performances, mais il est arrivé à la conclusion qu'on ne pouvait pas rivaliser en terme de performances avec du code moins "abstrait" (avec moins de couches). Et ce projet et assez vite retourné dans les cartons.

Evidemment, on peut me répondre qu'il s'y est mal pris, qu'il n'a pas pris la bonne lib, qu'il faut réessayer en 2011. Sans aucun doute. Mais je ne vois pas bien ce que cela peut nous apporter. Piwigo est très performant, plutôt facile à maintenir et à étendre. L'ajout de couche pourrait rapidement rendre le tout ingérable.

Donc pour moi, séparer le "métier" et "l'accès aux données", je comprends l'intérêt mais je n'applique pas sur Piwigo. Par contre, on a clairement séparé le "métier" et la génération du HTML. On utilise Smarty pour cela. C'est plus propre et plus performant que la génération de HTML directement depuis le PHP.

L'exemple très pénible pour les erreurs de syntaxe, c'est le "select fieldA from tableA group by field2". Cela ne fonctionne pas en PostgreSQL. Il faut que tous les champs du select soit dans le group by. Mine de rien, ça nous oblige à changer pas mal de requêtes ce genre de chose.

Pour l'exemple de requête qui ne retourne pas la même chose avec PostgreSQL, ce que je retrouve sur notre bugtracker, c'est surtout des changements faits pour PostgreSQL qui ont pour conséquence de casser ce que MySQL retournait, par exemple sur une requête comme :

SELECT c.uppercats, COUNT(DISTINCT i.id) AS img_count
  FROM '.IMAGES_TABLE.' i INNER JOIN '.IMAGE_CATEGORY_TABLE.' AS ic ON i.id=image_id
    INNER JOIN '.CATEGORIES_TABLE.' c ON c.id=category_id
  '.$where_sql.'
    AND date_available=\''.$dates[$i]['date_available'].'\'
  GROUP BY category_id, c.uppercats
  ORDER BY img_count DESC
  LIMIT '.$max_cats.'
;';

en Postgresql ça retourne des lignes sans doublons, mais en MySQL on a des doublons. Donc on rajoute un DISTINCT, mais alors ça ne marche plus avec PostgreSQL : un peu galère.

Je veux bien te croire. Peux-tu donner des exemples de librairies qui font ça super bien ?

Dans le cas de Piwigo, on ne partait pas de rien, mais d'un existant dans lequel les requêtes SQL étaient au milieu du code PHP (certains trouvent ça horrible, moi pas du tout, bien au contraire). Pour éviter de réécrire 98% du code on a choisi la méthode 2, qui minimisait l'impact sur le code.

Peut-être qu'on aurait dû choisir la méthode 1 en trouvant une super librairie, au prix d'un chantier énorme et donc très long et qui allait apporter obligatoirement des régressions. Sauf que "est-ce que cela valait le coût ?". Je ne pense pas. Pour l'énorme majorité du public utilisateur de Piwigo, le moteur de base de données n'a pas d'importance. Il faut juste que ça marche. Les utilisateurs préfèrent qu'on passe du temps à améliorer l'interface utilisateur par exemple plutôt qu'à refaire Piwigo pour des questions techniques qui leur passent complètement au-dessus.

Si aujourd'hui je devais refaire une application web, non distribuée, la question serait tout autre et faire du PostgreSQL ou utiliser une librairie d'abstraction, pourquoi pas !

Et la charge du serveur est même égale (ou moindre, je ne sais plus)
à la version précédente en PHP.

Voilà qui dément mes expériences passées. Tant mieux. J'avais du mal à croire que RoR soit si populaire (ait été plutôt, c'est moins la "mode" qu'il y a 3 ans) sans avoir les performances qui allaient avec. Il faut croire que soit je n'avais pas trouvé les optimisations nécessaires pour faire tourner RoR sur mon serveur, soit que l'application que j'utilisais était mal codé du point de vue performances.

Oué enfin c'est pas le seul a avoir ces avantages... ça n'a rien de mieux sur
ce point par rapport à du postgresql (qui me parait par contre beaucoup plus
robuste par exemple)

Attention, je ne dis pas que PostgreSQL n'est pas bien. Personnellement, pour avoir travaillé avec MySQL énormément, Oracle beaucoup, PostgreSQL pas mal aussi et SQLite un peu : pour moi le meilleur techniquement parlant c'est PostgreSQL, sans conteste. La doc est excellente, les messages d'erreurs sont très bien faits, la gestion de l'intégrité référentielle est "incluse", les types de données sont simples. MAIS c'est moins disponible que MySQL. Donc pour une application distribuée comme Piwigo, c'est un critère majeur.

Y'a aucune lib php qui permet d'abstraire les accès aux bases ?

Il y a plusieurs stratégies pour faire du code indépendant du moteur de base de données. Grosso modo :

1) on peut déléguer l'intégralité de la gestion du code SQL à une librairie et réinventer le "select url from photos where id=123" en quelque chose du genre "sqlget(arary('id'), 'photos', array('id'=>123))". L'inconvénient de cette méthode, c'est qu'elle semble sympathique sur des exemples triviaux, mais c'est ingérable sur des exemples "de la vraie vie". Au final, je trouve que ça complique le code et ça génère des requêtes SQL génériques, pas du tout optimisées.

2) ou bien fait des requêtes SQL qui marchent théoriquement partout. L'inconvénient de cette méthode, c'est que les moteurs de base de données ont beau être compatible avec les normes ANSI SQL92 par exemple, en pratique, c'est faux. Il arrive souvent qu'une même requête soit incorrecte en PostgreSQL voire pire, ne donne pas les mêmes résultats en MySQL et en PostgreSQL (testé et approuvé malheureusement).

Dans notre cas, les requêtes SQL de Piwigo sont assez travaillées côté optimisation des performances. Ce n'est pas forcément un critère important pour tous, mais pour nous c'est assez critique.

Et pourtant on est en train de commenter sur un site fait en Rails. Et le moins
qu'on puisse dire c'est que ça tourne quand même plutôt convenablement, non ?

Tout dépend de la machine que tu mets derrière. Si tu as un petit espace sur du mutualisé, il y a à mon avis plus de chance que ton appli RoR soit coupée que ton appli PHP. Sauf si tu as choisi une appli PHP codée avec les pieds, et il y a en probablement beaucoup, et le "codé avec les pieds" est très subjectif de toute façon.

Là pour moi, il y a un problème. Pourquoi obligé à utiliser un SGBDR particulier ?

Piwigo 2.2, la version stable actuelle, est compatible avec MySQL et expérimentalement compatible avec PostgreSQL et SQLite. Après plus d'un an "d'expérimentation", de récentes discussions au sein de l'équipe de développement nous amènent à la conclusion que Piwigo ne supportera bientôt plus PostgreSQL et SQLite. Pourquoi ? parce qu'être compatible avec PostgreSQL apporte des contraintes pénibles de développement, empêche d'optimiser les requêtes efficacement et globalement les développeurs ne suivent pas : de nombreux bugs spécifiques à PostgreSQL ne sont pas corrigés et la quasi totalité des plugins n'est compatible qu'avec MySQL. Les utilisateurs testeurs sur PostgreSQL ne peuvent pas utiliser les plugins voire même certains thèmes et c'est très frustrant. C'est dommage, mais nous allons nous reconcentrer sur MySQL, qui présente de nombreux avantages : disponibilité, libre, gratuit, performant. (le jour où MySQL ne présentera plus ces avantages, il sera temps de changer)

Vouloir être compatible avec plusieurs SGBD, c'est bien en théorie mais en pratique, c'est une charge de travail supplémentaire et au final, il faut être réaliste : les utilisateurs s'en moquent complètement. Les utilisateurs, ils veulent que ça marche, pas que les contraintes d'intégrité référentiel soient gérées de telle ou telle façon. Désolé si c'est trop pragmatique mais c'est mon expérience.

Enfin ce que je voulais dire, c'est que je n'ai pas trouvé l'info du SGBD qu'ils utilisaient pour MediaGoblin. Enfin si, avec un peu plus de recherche, j'ai trouvé qu'ils utilisaient MongoDB, qui n'est pas un SGBD. Donc tu ne pourras pas utiliser PostgreSQL, mais à mon sens cela n'a rigoureusement aucune importance.

[à propos de la vélocité de Python] Ça c'est gratuit. D'une part il n'est
pas avéré que python soit plus lourd que PHP

Encore une fois, je constate de manière empirique sur des exemples concrets (probablement pas assez nombreux pour en tirer une conclusion générale), mais lorsque j'ai fait tourner du Ruby On Rails ou du Python, le serveur avait vraiment du mal à suivre et la conséquence était une dégradation rapide de la qualité de service pour les visiteurs du site. Les applications équivalentes en PHP n'avaient quasiment pas d'incidence sur la consommation CPU/RAM du serveur.

J'adore Trac, mais c'est bien parce que je n'ai pas trouvé d'équivalent en PHP que je le garde.

Il faudrait sans doute que je me penche sur des solutions d'optimisation des performances de Python pour le web, mais "out of the box" avec apt-get, mon expérience c'est Python = lent et PHP = rapide. Cela ne signifie pas que Python = nul et PHP = génial. Cela veut plutôt dire que je réserve PHP à certains usages et Python à d'autres.

Donc il s'adresse plus précisément à ce genre de personne [ceux qui] ont
un serveur virtuel, un serveur dédié ou qui sont autohébergé

OK, alors effectivement ça change tout, ils visent une niche vraiment petite (pour le moment, dans 5 ans, ce sera peut-être la majorité)

J'ai vu une démo grâce à un lien trouvé un peu plus haut et effectivement, l'orientation me semble un peu différente de Piwigo. Avec Piwigo, tu créés ta galerie photo perso (que tu personnalises). Piwigo permet de faire du multisite, mais chaque "site" est indépendant des autres. Avec MediaGoblin, tu créés un compte sur un site de partage de medias. C'est un niveau "au dessus", une meta-galerie. Le concept est intéressant. Du coup, avec MediaGoblin, il y a 2 publics : d'abord celui qui installe le logiciel, il faut quelqu'un d'assez technique avec des prérequis pas triviaux, ensuite les utilisateurs qui se crééent un compte sur la plateforme, et là je dirais que c'est "monsieur tout le monde" (et ça c'est bien => populariser les services décentralisés).

Celui qui installe MediaGoblin devient un hébergeur de galeries photos, avec les contraintes que cela impose quand même : quelle est la responsabilité de l'hébergeur sur le contenu de ses utilisateurs ? qui supporte les coûts d'hébergement ? Bref, c'est une problématique différente de celle de Piwigo (mais qu'on retrouve en revanche sur Piwigo.com = plateforme d'hébergement de galeries Piwigo)

Piwigo ne gère que les photos

C'est le métier principal et prioritaire de Piwigo. Mais on peut aussi y déposer des vidéos et n'importe quel type de document.

Je suis le fondateur de Piwigo.

En effet, la licence est différente : GNU MediaGoblin = AGPL, Piwigo = GPL.

La technologie est différente : GNU MediaGoblin = Python/?, Piwigo = PHP/MySQL. Là je souhaite bonne chance à GNU MediaGoblin pour 1) faire une appli véloce qui ne consomme pas 130% du CPU sur le serveur 2) réussir à distribuer une application qui a des prérequis assez peu disponibles (PHP est largement plus disponible que Python sur les serveurs mutualisés)

L'orientation en revanche, me semble assez similaire. En quoi est-elle différente selon toi Michel ?

Mais oui, la diversité c'est bien et cela ne fait pas de mal. Piwigo fêtera ses 10 ans en 2012 et n'a jamais évolué autant qu'en ce moment. Les "grosses pointures" dans le domaine des logiciels libres du partage de photos sont Menalto Gallery (le plus ancien), Piwigo, Zenphoto (le plus jeune).

Pour ceux que ça intéresse, voici un récent concurrent openphoto http://theopenphotoproject.org/ (qui selon moi a pour critère de différentiation principal qu'il fait les choses à l'envers par rapport à de nombreux logiciels libres : d'abord le marketing, les promesses et les finances, ensuite le développement; et ce n'est pas forcément une mauvaise voie)

Piwigo, logiciel libre de création de galerie photo sur le web, sera donc présent lors de ces journées du logiciel libre à Dijon. Programme complet des ateliers sur http://fr.piwigo.org/forum/viewtopic.php?id=20252 : certains ateliers sont plutôt orientés "découverte et utilisation basique", d'autres "utilisation avancée" et pour certains "développement et contribution".

Des métiers [...] se marginalisent [...] c'est le cas des photographes. Il
en restera quelques-uns comme il reste des selliers, des potiers, des souffleurs
de verre

Cela me semble bien trop simple et au contraire, je ne pense pas que le métier de photographe soit proche de la fin.

Le métier de photographe, cela ne signifie pas uniquement partir 3 semaines au Népal, revenir avec de superbes photos et prier pour trouver un magazine qui voudra bien payer pour diffuser son reportage photo.

Une bonne partie du travail de photographe, ce qu'ils appellent souvent de "l'alimentaire", c'est tout simplement répondre à la rédaction d'une revue sur une demande précise comme "on a besoin de 5 photos pour illustrer notre article sur le service pédiatrique de l'hôpital du coin", le photographe y va, fais ses 150 photos, qu'il envoie à la rédaction qui en sélectionne 5, le photographe est payé pour la commande.

Ce principe fonctionne aussi avec des agences de relation presse qui lors de la nomination de Thierry Ducros à la direction générale des usines Tourneporc, font réaliser un reportage sur lui pour une publication en interne de la société.

Et dans le genre "commande", il y a le fameux "photographe de mariage", certes concurrencé par le cousin Kevin et son nouveau réflex Nikon qu'il a eu à Noël (sauf que Kevin ne sait pas trop comment éviter les yeux rouges, tant pis pour la mariée).

Bref, on ne "commande" pas ce genre de reportage à des amateurs, le métier de photographe ne disparaîtra pas tant qu'il y aura ce type de demande.

En tant qu'éditeur de logiciel de galerie photo pour le web (Piwigo) et hébergeur de galerie photo (Piwigo.com) je côtoie depuis longtemps le métier de photographe et il me semble clair que d'un point de vue qualitatif, on trouve des amateurs qui font largement aussi bien que des professionnels sur les sujets qu'ils ont choisi de traiter (très souvent, c'est des paysages, les oiseaux, la vie des pucerons sur les feuilles avec de la rosée...). Et là effectivement, si une revue a juste besoin d'une illustration d'une montagne avec le soleil couchant, elle trouvera sans problème de la super qualité sans passer par un pro et donc à des prix ridicules. Là où l'amateur ne suivra jamais, c'est dans la réalisation d'une commande.

Non non, j'aurais dû faire une phrase plus longue pour éviter les quiproquos : les fichiers CSS sont fusionnés en un seul fichier CSS, les fichiers Javascript sont fusionnés dans un seul fichier Javascript (quand c'est possible)

proposer le choix entre différents SGBDR comme MySQL, PostrgreSQL et SQLite?

Hum... c'est déjà le cas. Même si PostgreSQL et SQLite sont proposés à titre "expérimental", car pas aussi bien supporté que MySQL (notamment par les plugins, mais aussi par le core parfois, il y a des bugs à corriger).