J’ai installé OpenFire 3.6.4 sur une vieille machine sous XP, et il tourne très bien. Je ne sais pas configurer la JVM, et ce n’est pas grave, ça tourne. La machine est évidement dédié à ça (et à Wyse Device Manager).

Comme client, j’ai choisi Pandion, et les deux s’entendent plutôt bien. Il n’y a que la recherche des utilisateurs qui ne fonctionne pas.

OpenFire s’est très bien interconnecté avec mon Active Directory, malgré quelques petites spécificités de ce dernier. Du coup, il m’a intégré les machines, par exemple…

J’ai aussi récupérer les groupes de sécurité, et la fonctionnalité qui permet de dire que toutes les personnes d’un même groupe (et éventuellement d’autres groupes) sont automatiquement amis est géniale !

Je me suis servi du plugin « Kraken IM Gateway » pour avoir une passerelle avec WLM. Lui est plus mal foutu… mais fonctionnel…

OpenFire est peut être vieux et pas maintenu, il est quand même génial, complet et fonctionnel !
Et puis, il y a le projet RedFire qui semble être l’avenir de OpenFire.
J’ai vu aussi qu’il y a une version bêta de OpenFire 3.7.0.

Ce sont les clients modernes qui me manque… Pandion est le seul, sous Windows, en français, avec une bonne gueule, stable et léger…

Installation facile puisqu’il est dans les dépôts, configuration un peu moins à cause du langage un peu exotique dans lequel il est développé (erlang), mais rien d’insurmontable, il y a beaucoup de documentation et tutoriels sur le net (d’après ce que j’avais compris à l’époque c’est le jabber à la mode en ce moment) et le fichier de conf par défaut est assez bien commenté.

Niveau fonctionnalités utilisées : identification sur un annuaire OpenLDAP, remplissage des profils (nom, prénom, pseudo, mail, numéro de tel… grâce aux données de l’annuaire, et une seule liste de contacts qui est la même pour tout le monde et est mise à jour automatiquement dès l’ajout d’une nouvelle entrée dans l’annuaire.

Pour le client on avait laissé le choix et certains utilisaient spark, d’autre pidgin, gluxmpp, psi…

Il est beaucoup utilisé en journée et on a jamais eu à se plaindre des performances !

Comment mon MSN va savoir et rooter mes messages a un Membre A qui s’est connecté sur le Serveur d’entreprise ?

Est ce que c’est le serveur d’entreprise qui doit se déclarer auprès du reste du monde ? Et exposer tous ses membres ? Puis filtrer via de la « glue » Java ?

Mais je ne comprends toujours pas comment s’intègre le Chat de l’entreprise avec le monde externe ?

Je m’explique:
- L’entreprise a besoin d’un serveur Jabber pour le Chat
- Elle peut déployer des clients Jabber (web ou soft) pour que les gens communiquent entre eux.

Mais:
- Comment font les gens qui ont déjà un client Jabber (Yahoo, MSN, GTalk) ? Il ne vont quand même pas utiliser 2 outils ? QUID de l’iPhone & co ?
- Comment depuis mon compte Jabber de mon entreprise je vais pouvoir discuter avec des externes ?

D’après ce que j’ai compris:
- Les Serveur Jabber se déclarent en cascade pour rooter correctement l’information.
- Il existe des « proxy » Jabber pour MSN, Yahoo, GTalk …

Si vous avez des détails sur ce genre d’architecture je serais preneur ! Car reinventer une roue limité au cadre de l’entreprise c’est un peu moyen …

C’est vrai qu’il a été conçu à la base pour être utilisé dans les jeux, mais pour faire de la conf audio, ça marche nickel.

http://mumble.sourceforge.net/

par contre le gros reproche que j’ai a faire, et qui ma fait supprimer openfire c’est l’utilisation mémoire, alors oui ça se configure en modifiant les options de lancement, mais c’est bcp plus complique que la conf du serveuren lui même, et surtout l’occupation mémoire mini est bornée, je sais plus a combien mais le min correspond a plus que ce que consomme ejabberd, genre 2fois plus
bien sur c’est pas 4go de ram qu’il faut, mais sur un seveur avec 128mo + lamp ça occasionne du swap regimierement, et donc des ralentissements et de l’usure pour le dd

Sinon complètement hos sujet: les images sur la version iPhone du site sont pas redimetionnees, enfin chez moi, c’est juste moi qui ai ce souci?

Il y a surement moyen de bloquer le transfert de fichier entre utilisateur…..

Franchement ce serai vraiment cool de mètre en place ce genre de truc !!!!

Bef, je pense que je vais me lancer… d’abord à la recherche des docs et tutos, ensuite on passera à l’application…

Enfin, je reste preneur de conseils avisés,bien entendu!

Amicalement

@jinh: merci pour ces infos, je m’y pencherai plus sérieusement dès que j’aurai du temps

http://www.bivouak.fr/post/2009/07/25/Google-Wave-s-ouvre-un-peu

http://googlewavedev.blogspot.com/2009/07/google-wave-federation-protocol-and.html

Sans te mentir, à l’époque (il y’a 6 mois), j’ai repris le travail d’un collègue, donc je n’ai pas de étude comparative exhaustive sous la main.

Cependant, OpenFire répondait à l’ensemble des besoins que nous avions identifié grâce aux plugins qui existent. Il faut cependant bien garder à l’esprit que le déploiement d’un tel serveur est d’une facilité déconcertante, tout comme l’ajout de plugins sous forme d’archives Java (JAR ou WAR).

Ok, tu vas me dire, l’installation, c’est bien beau mais en terme de configuration ?

C’est tout aussi accessible, les menus sont bien découpés, pas de scripts obscures à aller modifier à la mano.

En fait, un des points qui a nous conduit à ce choix était justement qu’il soit écrit en Java puisque nous avions envisagé de rajouter des fonctionnalités supplémentaires via des modifications de code source ou le développement de plugins.

Concernant l’optimisation de la JVM, je te conseille tout d’abord de lire les deux articles sur le site de Sun :

http://java.sun.com/performance/reference/whitepapers/tuning.html
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

Finalement, pour une application de type Openfire, amené à tourner constamment en production, l’option qui est incontounable est -server, car elle permet d’optimiser plus de code (compilation en code natif avec une phase de profiling). Le revers de la médaille est que l’application met plus de temps à se lancer, ce qui n’est pas préjudiciable pour une telle application vu la fréquence des arrêts/redémarrages.

De nombreux articles sur Internet traitent de ce sujet, mais attention toutefois à ne pas faire confiance aveuglément aux benchmarks (d’autant plus lorsqu’ils comparent du C++ avec du Java…. Je te renvoie vers un exposé que j’avais fait il y’a pas longtemps qui explique bien le problème (c’était dans le cadre de mes études, c’est assez succinct mais on peut toujours en parler ensuite) : http://www-igm.univ-mlv.fr/~dr/XPOSE2008/Benchmarking%20et%20optimisations%20en%20Java/.

Effectivement, il faut quand même avouer que la tendance à affirmer que « le Java c’est lent » est historique (au début, c’était le cas) et fortement renforcée par des tests de performance régis par un protocole erroné.

Concernant Java, as-tu des liens intéressants concernant l’optimisation de la JVM ?

J’ai déployé il y’a quelques mois de ça OpenFire dans le cadre d’une utilisation professionnelle.

Il n’est pas très gourmand en ressources, il suffit de disposer d’un peu de RAM, qui dépend fortement de la montée en charge et du nombre d’utilisateurs simultanément connectés ( les détracteurs du Java sont souvent les personnes qui ne savent pas comment configurer un tant soit peu leur JVM, je dis ça sans animosité).

A savoir que pour ceux qui souhaitent faire de la videoconférence, il existe un plugin Red5 (qui utilise du flash derrière).

Il est même possible d’associer les comptes Jabber à des comptes SIP pour des configurations plus avancées.

Enfin, et c’est un point appréciable je trouve, il est possible de s’interfacer avec un LDAP pour synchroniser les comptes utilisateurs.

Bien sûr, le point bloquant est, comme l’a exprimé Nyco, le statut du projet OpenFire, à savoir bien endormi malgré une communauté ma foi encore assez active.

En résumé, pour une uilisation dans le cadre privé, c’est très satisfaisant. Pour une utilisation professionnelle, c’est un peu limite car nous avons aucune visibilité sur l’évolution future de la solution.

Généralement, on recommande effectivement Openfire (projet en sommeil, voire abandonné), ou bien ejabberd comme serveurs, ou encore Tigase (Java) et Prosody (Lua, très jeune projet). Côté clients, on recommande plutôt Gajim et Psi, qui assez fiables et stables, et surtout qui ont beaucoup de fonctionnalités XMPP, tout en étant très respectueux des standards.

Sur l’échange de fichiers, c’est assez difficile en P2P, donc la plupart du temps, les clients utilisent des proxies… à fournir côté serveur. Donc si tu ne veux pas d’échanges illégitimes ou illégaux de fichiers, tu ne mets pas en place de proxy, et voilà, on ne pourra pas t’accuser de quoi que ce soit de ce côté. Si c’était la seule chose qui te retenait pour faire tourner un serveur XMPP, alors tu peux y aller.

Trés intèressant ton article… je tenterais bien l’experience (si je trouve un peu de temps surtout…, histoire de me dire que
je peux faire autre chose de mon PC que de la bureautique et multimédia…

Cependant, étant totalement néophyte en la matière de serveur, est-ce que cela est facilement réalisable malgré tout? Faut-il un config matériel d’enfer, ou bien cela peut-il être installé sur un config un peu ancienne?
Dernière question, si j’envisage de réaliser cela au niveau « famillial », à partir de quel bande passante (débit) cela devient envisageable?

Merci d’avance pour vos lumière…

Donc, je déconseille vivement openfire, désolé

Plus concrètement, as-tu essayé plusieurs serveurs XMPP ? Pourquoi avoir choisi OpenFire (qui est codé, si je me souviens bien, en Java, avec les désagréments que ça apporte -avis personnel-) ? J’ai installé un eJabberd sur mon serveur (gentoo OVH), mais j’ai rencontré pas mal de soucis au niveau de la config, mais ça vient sans doute en partie de la distrib lourdement customisée à la base.