J'ai quelques interrogation sur l'architecture logicielle de MiniG (sans être rentré en profondeur dans les entrailles du softs).
DISCLAIMER : je trouve l'ui vraiment bien et je suis très intéressé par le soft.
1/ quel est l'intérêt de séparer deux exécutions java pour minig : le backend et le frontend, sachant que tomcat au démarrage de l'application peut lancer le backend sans soucis dans sa propre instance java, ça complexifie le déploiement alors qu'il me semble qu'un simple war pourrait faire l'affaire.
2/ quel est l'intérêt d'utiliser des morceaux d'eclipse qui utilisent du jni ça limite fortement le "run everywhere", en effet sur mon FreeBSD je me retrouve obligé de recompiler des morceaux d'eclipse pour avoir eclipse_1020.so et eclipse_1115.so afin de tester les snapshots mis à disposition. Est ce que l'avantage des bibliothèques d'eclipse utilisées (celle qui nécessite le jni) est si important au niveau de la facilité de code qu'il est *vraiment* plus inétressant de les utiliser ? je trouve que ça complexifie le packaging (je voudrais faire un ports FreeBSD) et limite la portabilité.
3/ le backend (dont je ne comprends toujours pas pourquoi il ne tourne pas directement dans tomcat :)) utilise un script bash pour démarrer alors qu'un script shell posix ferait largement l'affaire (enfin ça je fournirai un patch dès que j'aurais compris l'intérêt de ne pas mettre le backend dans le tomcat).
4/ Pourquoi des chemins vers des fichiers de configurations en DUR et très linux-only (/etc/...) pour le packaging FreeBSD moi j'aurai je voudrai les mettre dans /usr/local/etc/minig par exemple (enfin ça doit pas être trop compliqué à mettre en oeuvre.
il serait vraiment intéressant pour minig de ne fournir qu'un seul war a déployé (même si à l'intérieur il y a une séparation backend frontend) ce serait beaucoup plus simple à mettre en oeuvre tester et tout.
Dans l'ideal un soft comme ça ce que je trouverai intéressant c'est un war unique que l'on déploie.
Il gère sa conf dans son WEB-INF.
Il détecte une première installation en fonction de la présence ou non de son fichier de configuration ou une upgrade qui nécessite des changements de conf en fonction d'un tag (de version par exemple) dans son fichier de conf et qui lorsque l'on pointe le navigateur dessus propose un wizard pour faire tout le nécessaire.
J'imagine que ce serait plus simple.
J'espère que mon post est compréhensible et que les devs comprennent bien que je ne crache pas du tout sur minig, j'essaye d'être constructif et de comprendre une archi qui de prim'abord me parait étonnante.
# MiniG quelques interrogation sur l'archi
Posté par Bapt . En réponse à la dépêche Groupware OBM et Webmail MiniG, paquets Debian. Évalué à 3.
DISCLAIMER : je trouve l'ui vraiment bien et je suis très intéressé par le soft.
1/ quel est l'intérêt de séparer deux exécutions java pour minig : le backend et le frontend, sachant que tomcat au démarrage de l'application peut lancer le backend sans soucis dans sa propre instance java, ça complexifie le déploiement alors qu'il me semble qu'un simple war pourrait faire l'affaire.
2/ quel est l'intérêt d'utiliser des morceaux d'eclipse qui utilisent du jni ça limite fortement le "run everywhere", en effet sur mon FreeBSD je me retrouve obligé de recompiler des morceaux d'eclipse pour avoir eclipse_1020.so et eclipse_1115.so afin de tester les snapshots mis à disposition. Est ce que l'avantage des bibliothèques d'eclipse utilisées (celle qui nécessite le jni) est si important au niveau de la facilité de code qu'il est *vraiment* plus inétressant de les utiliser ? je trouve que ça complexifie le packaging (je voudrais faire un ports FreeBSD) et limite la portabilité.
3/ le backend (dont je ne comprends toujours pas pourquoi il ne tourne pas directement dans tomcat :)) utilise un script bash pour démarrer alors qu'un script shell posix ferait largement l'affaire (enfin ça je fournirai un patch dès que j'aurais compris l'intérêt de ne pas mettre le backend dans le tomcat).
4/ Pourquoi des chemins vers des fichiers de configurations en DUR et très linux-only (/etc/...) pour le packaging FreeBSD moi j'aurai je voudrai les mettre dans /usr/local/etc/minig par exemple (enfin ça doit pas être trop compliqué à mettre en oeuvre.
il serait vraiment intéressant pour minig de ne fournir qu'un seul war a déployé (même si à l'intérieur il y a une séparation backend frontend) ce serait beaucoup plus simple à mettre en oeuvre tester et tout.
Dans l'ideal un soft comme ça ce que je trouverai intéressant c'est un war unique que l'on déploie.
Il gère sa conf dans son WEB-INF.
Il détecte une première installation en fonction de la présence ou non de son fichier de configuration ou une upgrade qui nécessite des changements de conf en fonction d'un tag (de version par exemple) dans son fichier de conf et qui lorsque l'on pointe le navigateur dessus propose un wizard pour faire tout le nécessaire.
J'imagine que ce serait plus simple.
J'espère que mon post est compréhensible et que les devs comprennent bien que je ne crache pas du tout sur minig, j'essaye d'être constructif et de comprendre une archi qui de prim'abord me parait étonnante.
Je le trouve très très intéressant comme webmail.