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.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par Pierrick Le Gall . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 5.
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.
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.
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)
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.