[AlternC-dev] LDAP / Postgres, le retour

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Patrick Vander Linden pvdlinden at belzebyte.com
Mar 26 Avr 14:30:04 CEST 2005


Le mardi 26 avril 2005 à 11:48 +0200, Benjamin Sonntag a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Patrick Vander Linden wrote:
> 
> | Hello,
> |
> | Je me présente, Patrick Vander Linden, unix lover indépendant.
> |
> | J'utilise alternc depuis un petit temps déjà, et je voudrais
> | participer à son développement.
> |
> | Dans les environnements distribués que je déploie, mysql n'existe
> | pratiquement pas. J'utilise principalement postgresql et ldap.
> |
> | Sans rentrer dans un débat mysql vs postgresql, ou un débat
> | concernant ldap, je me demandais si ca pourrait intéresser le
> | projet d'intégrer la possibilité d'utiliser postgresql et/ou ldap
> | en plus de mysql. Le choix étant laissé à l'utilisateur au moment
> | de l'installation.
> 
> | Je me demandais aussi si l'utilisation d'un module de template
> | comme smarty, ne permettrait pas une customisation plus grande des
> | interfaces.
> |
> Bonjour,
> 
> Nous avons abandonné ldap il y a un an et demi environ, pour la
> gestion du mail, car même en sarge, ldap reste un outil disposant de
> beaucoup trop peu de visibilité technique et d'outils à notre gout
> pour être aussi confiant que mysql ou postgres.
> C'est un peu le même parallèle que choisir ext3 ou xfs, xfs est
> peut-être très bien, mais le peu d'outils de déboguage, et le peu de
> personnes maitrisant xfs "en interne" fait un peu peur, tandis que
> pour ext3, je connais au moins 4 personnes dans mon entourage qui
> parlent le debugfs couramment. Ca rassure ...
> 
> Bref, pour ldap, je ne vois pas trop ce que cela pourrait apporter au
> projet, ce serait à approfondir.

Je ne suis pas entièrement d'accord, mais bon je respecte ce choix. Pour
moi openldap, depuis la version 2.1.x reste un outil performant pour la
gestion centralisée de services et d'utilisateurs dans un réseau de
serveurs. Comme je voudrais intégrer alternc dans ce type
d'infrastructure, je ne crois que je vais pas abandonner l'idée de
permettre à alternc de le faire. Mais bon, pour l'instant je botte en
touche et je reviendrai vers vous une fois que ce projet aura mûri un
peu plus.

> 
> Pour postgresql, je pense que c'est une excellente idée, tout d'abord
> de faire un module alternc-postgresql qui proposerait aux hébergés de
> disposer de bases de données postgres, de la même manière que le
> module m_mysql.php pour mysql actuellement. Tout en laissant le coeur
> d'AlternC sur une base mysql.

Si personne n'y voit d'objection, je vais m'atteler à créer ce module.
ceci me permettra de me familiariser vraiment avec l'api d'alternc.

> 
> Ensuite, si vous en avez le courage, pourquoi en effet ne pas proposer
> une version d'AlternC fonctionnant avec postgresql comme base de
> coeur, plutôt que mysql. honnêtement je n'en vois pas l'intérêt (merci
> de m'éclairer sur ce point en terme d'avantages / inconvénients) si ce
> n'est pour s'intégrer dans une conf existante, ce qui est actuellement
> loin d'être un point fort d'AlternC (relire l'avertissement lors de
> l'installation : "")

Je voudrais en effet développer un peu plus les capacités d'intégration
d'alternc au niveau de structures existantes. Je le trouve pour
l'instant un peu trop dictatorial à ce niveau. Concernant le fait de
mettre postgresql au coeur d'alternc, cela permettrait d'offir une
solution postgresql only. Sans rentrer, comme je l'ai déjà dit, dans un
débat stérile postgresql vs mysql, pour moi les avantages de postgres
sont les suivants:

- Besoin en mémoire vive nettement réduit par rapport à mysql.

- Même si mysql supporte les foreign keys, transactions, ... depuis
l'avènement d'innodb, ces fonctionnalités au sein de postgresql sont
beaucoup mieux intégrées et performantes. Je ne sais pas si vous déjà
jouer avec l'implémentation innodb, mais pour moi ca reste un jouet pour
bidouilleurs (je sens que je vais me faire des amis ;)

- Le support des triggers, des 'sql procedural languages', ...
permettent de mettre une grande partie de la logique dans la db, ce qui
est très pratique quand on se trouve en environnement multilanguage
(php, perl, java, ...). L'utilisation des héritages en postgres est
aussi un vrai bonheur.

Pour alternc, la plupart des checks effectués au niveau de php, pourrait
ainsi être porté au niveau db, réduisant par là le nombre de lignes php
(quoique c'est pas tout à fait certaint cà :) 
Au niveau des interfaces web, phppgadmin est du meme niveau, selon moi,
que phpmyadmin
Quant à la vitesse, ayant travaillé sur les deux db, je ne peux pas
affirmé que mysql soit plus rapide de façon signifiante.

> 
> Pour les histoires de templates, c'est un tout autre débat : pour moi
> un language de templates comme smarty n'a absolument aucune utilité
> quand on voit la difficulté de prise en main de ce metalangage, autant
> utiliser php pour ce qu'il est : un langage de templates ! ! en clair,
> j'utilise php comme langage de template, la plupart du temps avec des
> api de haut niveau (ce qui est presque à 100% le cas pour AlternC) et
> ca me suffit bien. Je pense par exemple (et Jérome Moinet sera je
> pense d'accord avec cette opinion) qu'un effort pourrait être fait sur
> la mise en css propre du bureau afin de proposer plusieurs feuilles de
> style, façon zope/plone. De la sorte, il serait possible de proposer
> des bureaux réellement différents tout en conservant un code identique.
> 
> Pour ceux qui voudraient alors modifier le bureau plus profondément
> (notamment les fonctionnalités accessibles aux comptes AlternC, ou
> carrément faire une autre interface), je pense que smarty ne les
> aiderait pas vraiment, il faut alors qu'ils recodent les quelques
> pages php en utilisant l'API d'AlternC ...
> 
> Bref, smarty, je ne vois pas son intérêt actuellement, si vous avez
> quelques arguments (...) je suis preneur ;)

Ok pour l'effort au niveau des css, mais l'avantage de smarty est de
séparer la logique du contenu. Pas besoin d'éditer le code php pour
changer la logique de présentation. Quant à la difficulté de prise en
main du metalanguage, pour un graphiste ne connaissant pas php, la
difficulté d'apprentissage des bases de smarty est équivalente à celle
d'apprentissage de php. Envisager smarty se met dans le cadre ou ceux
qui codent et ceux qui font le design peuvent être des personnes
différentes. Mais bon, c'était juste une suggestion que je botte aussi
en touche alors.

Pour résumer, je vais m'atteler, si cela vous van aux tâches suivantes:
	1. création d'un module postgresql à l'instar de m_mysql.php.
	2. possibilité d'utiliser postgresql comme coeur d'alternc
	3. Démontrer que ldap reste utile à alternc :-)

A+

Patrick

PS: suis aussi un fan d'xfs :-D






Plus d'informations sur la liste de diffusion Dev