Thomas Cataldo a écrit 205 commentaires

Simplement parce que scala est encore jeune ou plutôt pas assez enseigné en écoles d'ingé.

Bref, j'ai l'impression qu'il s'agit d'une énième tentative de rentabiliser une pseudo suite collaborative (eg OBM, Open-Xchange, OpenChange, Zimbra, Zarafa, etc.), sans réelle volonté de créer un projet libre et communautaire de grande envergure, comme par exemple Samba ou Asterisk.

Ce qui est sur c'est que si vous n'aimiez pas OBM, vous risquez de détester Blue Mind l'équipe étant celle qui a initié et maintenu OBM pendant 10ans.

Pour l'aspect sans java, vous allez devoir attendre… longtemps.

La solution est surtout pensée pour fonctionner sur un serveur dédié, dans l'idéal sur une plateforme de virtualisation.

L'assistant d'installation se considère maître à bord, et va reconfigurer tout le système pour le mettre en "conf Blue Mind". Un des principes fondateur derrière la console d'admin et l'assistant d'install est de se dire que s'il est nécessaire de faire un ssh à la main pour paramétrer un truc ou changer un réglage, on a perdu :-)

L'assistant va donc refaire tes confs postgresql, apache, nginx, cyrus, postfix, etc.

Principalement un agenda partagé, avec organisation de réunions et gestion du free/busy entre les collaborateurs.

MiniG is not dead. Le projet est libre et hébergé sur google code.

Puis le libre, ce n'est pas forcément une question d'employeur, au moins pour minig et opush, deux composants libres (respectivement webmail et serveur activesync) utilisés par obm.

Désolé de vouloir contourner le problème numéro uno du web : le côté déconnecté.

Les sysadmins nous demandent des applis web pour éviter d'avoir à redéployer tout un parc et les users ne veulent perdre aucune feature.

Je développe un webmail et les utilisateurs ne me demandent plus le bouton refresh depuis que je push les infos sur leur navigateur toutes les 24sec.

Complètement d'accord.

Le résultat final est une appli full ajax tout en javascript avec un fichier js pour chaque moteur de rendu multiplié par le nombre de langues que l'on souhaite supporter.

Je l'utilises pour minig depuis plus de 2ans et je ne regrette absolument pas. Je peux faire transiter des objets complexes entre le navigateur et le serveur sans m'occuper de comment ils seront transmis sur le wire.

Si je dois lui faire une seule critique : il se base beaucoup sur le fait que les modèles mémoires de java et de javascript doivent être similaires en terme de récupération de ram. Malheureusement aucun moteur n'implémente sa collecte de ram comme java : les références croisées ne sont pas collectés par les navigateurs du moment. Les API de gwt évoluent petit à petit pour pouvoir régler ça.

En dehors de ce petit bemol, c'est vraiment génial, test du code dans mon navigateur et les erreurs s'affichent sous la forme de stacktrace java avec numéro de ligne. Refresh du navigateur pour exécuter le code tout juste sauvegardé dans eclipse. Permet un cycle de dev qu'on jalousai aux développeurs php avant.

Tu peux leur dire que par rapport à zimbra / scalix, notre serveur activesync est libre ;-)

L'utilisation de dovecot n'est pas testée mais je ne vois pas pourquoi celà ne pourrait pas fonctionner. Au niveau du packaging le backend minig dépend de cyrus, mais en fait ce n'est pas un pré-requis absolu.

Il est tout à fait possible d'associer des factures à des projets via les modules projet et facturation de OBM.

En fait MiniG est parfaitement installable sans OBM, il affiche alors son propre formulaire d'authentification au lieu de reposer sur le mécanisme SSO de OBM.

Je teste régulièrement opensolaris dans des machines virtuelles kvm, et malheureusement, il ne fonctionne pas encore super bien là dedans. Le problème peut venir de kvm bien sur...

Le problème principal est la stabilité du network : avec le driver e1000 mon réseau "bloque", du genre tout marche dans le firefox d'opensolaris, mais dès que j'utilise le package manager, mon téléchargement se bloque en cours et il me dit que mon réseau ne marche pas.

Je suis très tenté de l'installer directement sur une partition de mon portable (kernel 64bit éprouvé + zfs + machines virtuelles java solaris sont des arguments de poids) mais comme en virtualisé il ne marche pas tip-top, suis un peu frileux pour l'installer directement.

Cette partie là est en cours de développement (c'est même tout récent vu que j'ai fait le premier commit il y a 3h pour le chat dans MiniG : http://code.google.com/p/minig/source/detail?r=400 ).

Ce qui marche aujourd'hui : l'annuaire managé par obm est compatible avec openfire, et quelques déploiements d'obm sont intérfacés avec des serveurs xmpp.

Avant tout merci pour vos retours constructifs

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.

L'objectif de cette archi à 2 jvm (plutot 3 sur install "réelle") est de pouvoir distribuer l'application sur plusieurs serveurs du type : un seul frontend avec uniquement l'ui gwt en javascript + les servlets gwt rpc, plusieurs backend MiniG, selectionnés par exemple en fonction du nombre de users connectés.

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é.

Les derniers builds disponibibles sur le site n'incluent plus les fragments (terminologie eclipse) qui comportent du code natif, car il ne sont pas utilisés sur mes plateformes de test (linux x86 et linux x86_64)

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).

C'est du bash plutot que du posix car je n'ai testé qu'avec bash, donc plutot que de mettre "/bin/sh" et que ça plante dès que "/bin/sh" n'est plus bash, je préfère "déclarer" dans mon script que je n'ai testé qu'avec bash.

Pourquoi pas dans le tomcat : l'objectif est de faire tourner le backend sur une machine séparée du frontend, de plus les recommandations officielles sur la plateforme equinox server sont d'utiliser plutot un serveur web "embedded in equinox" que "equinox embedded in server". Le backend n'est pas une "appli web j2ee" mais bien une "equinox server application".

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.


Oui, toute la conf est dans /etc/minig et c'est en dur. Suis pas très chaud pour avoir une variable de conf "conf_prefix=/usr/local" ou pour les mettre en relatif. Principalement parce que j'aime pas quand j'interviens sur un serveur devoir faire un "locate backend_conf.ini" (et me prendre un locate command not found un coup sur 2) pour savoir ou l'admin a déployé le produit...

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.


Oui l'archi est étonnante, elle permet au webmail de se comporter vraiment comment un client lourd, avec des threads dans le backend qui réalisent toutes les opérations que ferait un client lourd (gestion de cache, refresh auto des folders, indexation full text en tache de fond). Dans l'idéal vous avez 1 tomcat avec le frontend, 1 backend posé "pas loin" du serveur cyrus sur un autre serveur, et 1 serveur d'indexation solr posé sur un troisième serveur pour gérer les index fulls text des boîtes mail.

J'espère avoir répondu a une partie de vos interrogations.

je me dis que faire un module webmin pour l'administration d'OBM pourrait aider

Comme on aime bien se chambrer dans l'équipe OBM, je la note celle là pour la ressortir la prochaine fois qu'on discute de l'ergonomie de certains modules :D

En fait il ne faut pas voir obm comme un webmin mais comme une solution intégrée "Annuaire + IMAP + Calendrier + interface client lours & pda + Webmail".

Essaie de mettre domino web access sur ta messagerie sun : marche pas. Essaie de faire marcher exchange avec ton openldap existant, marche pas non plus.

Donc si ta messagerie marche déjà, obm ne t'aidera pas à l'administrer. Par contre si tu dois remplacer un vieux notes et veux payer mon cher qu'une solution domino 8 complète, là OBM est interessant.

> - Absence de connecteur Libre avec Outllook

Ok

> - Manque de Souplesse sur l'agenda :

C'est à dire ?

> - Impressions des agendas baclées

Les impressions ont été completement refaites et font de beaux pdf maintenant

> - Connectivité funambol lourde à mettre en oeuvre et limitée à l'agenda (pas d'outil local sur pc)

Déjà agenda + contact, pas que agenda. Ensuite notre "connectivité" funambol est une sync-source dédiée pour OBM, donc simple à déployer quand on s'y connait en funambol, (sinon c'est la misère).
Cette couche de synchro sert à connecter des terminaux mobiles, perso ça me ferait mal de devoir cabler mon truc qui fait wifi/bluetooth/3g pour devoir le synchroniser. La nostalgie du petit logo activesync qui tourne ou du palm du grand père ?

> - Pas de compatibilités avec le format normalisé CALDAV

En cours. Pour avoir retesté recemment tbird + lightning avec le serveur caldav d'apple, un connecteur dédié du type de celui d'obm est aujourd'hui bien plus pratique (saisie d'url "complexes" pour l'utilisateur pour s'abonner à un/des agendas par exemple)

> - compatibilité avec Lightning ou sunbird toujours à la traine (ils en sont à la 0.7 de Sunbird)

Le trunk du svn fonctionne en 0.8 voire 0.9, et le connecteur subit une ré-écriture totale pour la version 2.2 d'obm, entre autre pour le rendre asynchrone, ce qui n'est pas une mince affaire avec les API tbird actuelles.

De plus lightning n'est pas encore en 1.0, donc inutile de dire que les APIs et le fonctionnement change très très profondemment d'une version l'autre. Quand lightning sera "API stable"/ 1.0, nous sortirons le connecteur qui va avec.

C'est vrai, il existe une brique non-libre, pour nos clients qui veulent rester dans le monde proprio sur le poste client.
Mais outlook + connecteur n'est qu'une étape de transition vers thunderbird + lightning + connecteur ;-)

Et en plus OBM a pour moi un sacré malus: les connecteurs sont close-source et payants.

Le code du serveur de synchro est en svn ici : http://svn.obm.org/svn/obm-sync/trunk et celui du connecteur lightning est sur http://svn.obm.org/svn/obm-mozilla-calendar/trunk donc tout est bien libre (sauf la partie outlook pour l'instant).

La même équipe que Milimail développe aussi le projet miliconvert http://miliconvert.org/ dont l'objectif (résumé) est de créer un altova mapforce like, c'est à dire un outil transformations XML, en libre.

Bien que la roadmap passe par des formats militaires pour valider le fonctionnement de l'outil, la transformation de tout format défini par un XML Schema est possible. Ce projet est interessant car peu de logiciels libres couvrent le périmètre d'altova mapforce ou stylus studio. Le logiciel est basé sur eclipse, est dispose ainsi de toutes les possibilités d'extension par plugins de cette plateforme.

Aujourd'hui, Java et MySQL ne font pas bon ménage : les timestamps mysql sont limités en [1970-2038] (avec des datetime ca marche...), leur précision est en seconde et non en millisecondes, et pas mal de choses implicites en Java du genre unicode et transactions sont optionnelles sur mysql.

Pour moi, développeur java devant greffer régulièrement des applications sur des bases mysql existantes, c'est une super nouvelle. A mon avis la première choses que sun va faire, c'est faire de MySQL une base supportant le minimum de fonctionnalité imposé par JDBC.

Aujourd'hui, mon quotidien avec mysql, c'est lutter avec des détails obscurs de configuration du type (extrait de la doc du driver jdbc mysql) :

useGmtMillisForDatetimes : Convert between session timezone and GMT before creating Date and Timestamp instances (value of "false" is legacy behavior, "true" leads to more JDBC-compliant behavior. default : false

Avec un peu de chance (pour moi), certains réglages "par défaut" de mysql vont changer de valeur...

LemonLDAP est évoqué dans la présentation FederID de Clément.

La DGA a-t-elle dans ses autres cartons d'autres projets comme ça ? Un Milifox, un Milioffice, un Milignome ? SourceForge a du souci à se faire, l'armée française est dans la place !

Oui, ils ont aussi le projet miliconvert http://admisource.gouv.fr/projects/miliconvert/

Il s'agit d'un mapper graphique xsd -> xsd, un peu comme altova mapforce, mais implémenté sous la forme de plugin eclipse basé sur GEF et XSD.

Si l'on parcours bien la news on remarque que clamav détecte 100% des virus sur le tests mis en valeur. Ce test porte sur 18 virus.

Si tu clicke sur le lien vers le test PC mag, ce dernier porte sur 606000 virus différents. Sur ce panel bcp plus exhaustif, clamav se place dans... les 3 derniers, avec 63% de détection.

C'est très dépendant du projet et fait plutot parti de notre offre de service que de obm.

Classiquement on configure la passerelle pour délivrer les mails en double sur le nouveau et l'ancien serveur de messagerie. On réutilise aussi des "bouts de code" de notre connecteur outlook migrer les anciennes données. Pour groupwise, je ne serai pas utilisateur régulier d'évolution je ne saurai pas que ça existe : jamais vu chez un client.