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
Attachment:
pgpmwmkL1r9_C.pgp
Description: PGP signature