OoO En cette soirée bien amorcée du jeudi 29 mai 2008, vers 22:08,
Sylvain GARCIA <sylvain.garcia@aliasource.fr> disait:
Je suis d'accord avec toi, cependant, actuellement d'OBM ne me permet
pas de faire cela. Lors de la conception du découpage des paquets nous
avons beaucoup réfléchi sur cette problématique. Pourquoi obm-core
devrait s'installer sur un serveur qui ne gère que la BD?? En fait
bien que obm-core inclut majoritairement du code PHP il faut voir
cela comme un "ensemble d'API" ( je précise, les guillemets ;-) ). La
problématique vient en fait de l'upgrade de la BD OBM. Lors des
développements des différentes versions d'OBM, nous utilisons les
"API" disponibles dans le code PHP pour le faire évoluer. En effet, si
une MAJ de BD entraîne un nouveau schéma pour le stockage des
évènements du calendrier ( par exemple) il est beaucoup plus simple
d'utiliser le code d'OBM pour faire cela plutôt qu'un script sql ou
shell seul. Le problème est donc pour les MAJ. Et là je n'ai pris
comme exemple que le calendrier, mais il existe aussi de la gestion de
projet, un CRM, etc, faire une MAJ de BD devient vite un enfer (
croyez moi :-D )
Tous ces scripts de mise à jour peuvent être exécutés à distance, non ?
Il y a bien une partie d'OBM qui constitue le coeur et qui va être le
composant central de la solution. C'est ce coeur qui doit s'occuper de
la base de données (qui n'est pas optionnelle). L'installation du paquet
obm-core va donc installer avec dbconfig-common la base de données sur
un serveur distant (qui ne contient qu'une base de données) et sa mise à
jour va exécuter des scripts PHP pour mettre à jour la base de données.
Mais bon, du coup, cela remet un peu en cause le paquet obm-ui qui s'il
dépend d'obm-core et est installé sur une autre machine va aussi vouloir
configurer une base de données, ce qui va perdre un peu
l'utilisateur. Mais comme pour le moment, il n'existe pas d'autres
paquets, il suffit d'intégrer obm-ui (un fichier de configuration pour
Apache) dans obm-core.
Une autre question pour Sylvain en fait. Avec les packages actuels, on
peut installer obm-storage sur une machine et obm-ui sur une autre, mais
c'est tout ?
Oui c'est exact, mais à terme on pourra installer les autres services
gérés par OBM sur d'autres machines, qui ont besoins chacun de
obm-conf.
Perso, je ne pense pas qu'il faut se projeter autant dans
l'avenir. P'tet que le découpage paraîtra plus évident une fois qu'il y
aura réellement un composant qui devra s'installer sur une autre
machine.
La situation actuelle, c'est qu'il y a deux paquets (obm-ui et
obm-storage) qui sont quasiment vides en dehors des scripts de postinst
(dbconfig-common inclus). J'ai déjà eu le cas avec uuwaf-preferences qui
se contente de configurer une base MySQL pour être utilisée avec uuwaf
(un peu comme obm-storage donc). Cependant :
- uuwaf-preferences est optionnel
- la base de données est tellement générique qu'elle peut utiliser
directement la couche d'abstraction du framework ; elle n'a donc pas
de code propre à elle
Il me semble que dans obm, le premier point n'est pas vérifié. Pour le
second, n'y-a-t'il pas dans obm-core du code qui n'est utile que pour
obm-storage ?
Découper un logiciel en plusieurs paquets a l'avantage de la modularité
(ce que tu cherches à obtenir). Toutefois, il y a aussi quelques gros
inconvénients :
- les utilisateurs peuvent rapporter des bugs contre chacun des
paquets, ne pas rapporter le bug contre le bon paquet, ne pas
consulter les bugs des autres paquets (on a fait l'erreur de couper
roundcube en deux paquets, ce qui n'a finalement pas apporté grand
chose, mais du coup, les utilisateurs sont un peu perdus)
- les mises à jour sont plus difficiles, il faut faire attention en
transférant les fichiers d'un paquet à un autre, il faut faire
attention aux versions, on peut casser une installation parce qu'un
des paquets n'a pas réussi à s'installer et le système sera alors
dans un état bancal (ce peut aussi être le cas avec un seul paquet,
mais c'est généralement moins grave)
- un paquet ne peut pas modifier les fichiers de configuration d'un
autre paquet (ce que tu résous en ayant deux mécanismes de
configuration de la base de données pour obm-core, l'une qui pose les
questions, l'autre qui récupère les réponses de obm-storage si elles
sont présentes ; il me semble d'ailleurs que ce n'est pas garanti que
les scripts de postinst vont s'exécuter comme tu l'entends vu qu'il y
a une dépendance circulaire.
Par contre, il est relativement aisé de couper en deux un package (même
s'il est bien sûr mieux de prévoir le coup dès le début, ce que tu
essaies de faire ici).
Et dans un autre message :
Suite a nos conversation et vos remarques, j'ai cherché un moyen de
regrouper les paquets. J'ai discuter avec Yann Dirson, un nouveaux
collaborateur de ma société et aussi DD.
Il en pense quoi du découpage ? :)
--
No fortunes found