Omega a écrit 104 commentaires

Ta confusion vient surement du fait que contrairement à IRC, Jabber a des serveurs normaux, et des composants pour les discussions de groupe. Donc pour accéder à une discussion sur le salon linuxfr@chat.jabberfr.org, il te faut déjà un compte sur un serveur Jabber normal (pas forcément jabber.fr), et ensuite demander à ton client de rejoindre un salon sur le serveur chat.jabberfr.org.

jabberfr.org n'est pas un vrai serveur Jabber. Jabberfr.org héberge juste quelques services pour Jabber, comme par exemple chat.jabberfr.org pour les salons de discussions.

jabber.fr est un des domaines du serveur Jabber de l'apinc : http://jabber.apinc.org

(mieux vaut ne pas dépendre d'un serveur externe).

Oui c'est sur, mais le problème c'est que pour avoir le message de présence il faut que le bot qui s'occupe de ça soit dans la liste de contacts de ces personnes. Si tous les sites font leur truc chacun dans leur coin, on va avoir plus de bots que de vrais contacts dans nos listes de contacts Jabber (d'accord, pour certains c'est déjà le cas).

JabberFR propose déjà un service permettant de récupérer ces informations : http://presence.jabberfr.org dont les sources sont bien entendues disponibles : http://omnipresence.codingteam.net

Si ça peut t'aider on a déjà fait un truc de ce genre pour JabberFR. On a un robot qui est tout le temps connecté, et qui attend des requêtes XMLRPC. Lorsqu'un nouveau message est posté sur le forum ou une modification faite sur le wiki, alors on envoie une requête XMLRPC et le bot envoie à ceux qui sont inscrits une notification.

Le bot est basé sur neutron, tous les détails sont dispo là : http://wiki.jabberfr.org/RobotJabberFR La page est un peu bordélique, c'est surtout la fin qui est intéressante.

Franchement, quel intérêt? IRC est ouvert et marche très bien, à quoi bon lancer un truc concurrent qui va diviser les forces? Freenode est très bien sur IRC, merci.

IRC a pas mal de problèmes, notament le fait qu'il est impossible de discuter entre les réseaux de serveurs, il faut donc une connexion par réseau, on revient presque au problème de protocoles proprio qui ne parlent pas entre eux.

En plus de nombreuses limitations de IRC ont été contournées avec des bidouilles pas standards, comme par exemple les Nickserv et autres Chanserv, qui d'un réseau à l'autre changent de nom, et ne s'utilisent pas toujours de la même manière.

On a fait une petite comparaison entre IRC et les MUC Jabber : http://wiki.jabberfr.org/Comparaison_entre_MUC_et_IRC . Cette comparaison essaie d'être objective, mais comme il est très dur d'être objectif, si jamais vous voyez des conneries, n'hésitez pas à corriger.

Et si les gens/contacts veulent du son et se voir par webcam ?

Pour la voix, il y'a au moins déjà Spark (http://wiki.jabberfr.org/Spark )et Jabbin (http://wiki.jabberfr.org/Jabbin ) qui gèrent ça.

Pour la vidéo ça va venir, à noter qu'il existe un client Jabber qui gère la voix et la vidéo depuis longtemps : NeosMT (http://wiki.jabberfr.org/NeosMT ), mais il est propriétaire, seulement pour windows, et utilise une méthode non standardisée et pas vraiment optimale pour la visio conférence.

Moi, je pense que l'on devrait supprimer [...] le carême

Tiens le carême est férié maintenant en France ? Ça va être dur de trouver 40 autres jours fériés alors.

En googlant j'ai vu que asterisk gère nativement Jingle, je n'ai jamais utilisé asterisk et je ne sais pas ce que permet exactement cette intégration de jingle, mais je pense que ça doit permettre de faire pas mal de choses que fait SIP avec asterisk, et surement de faire une passerelle entre Jabber et SIP.

- Gestion des voicemails

C'est à dire ? Une boîte vocale centralisée ? C'est défini dans le protocole ça, ou alors c'est juste un plugin au niveau du serveur qui gère ça ? Ça me semble pas très difficile de faire que le serveur réponde si le client ne répond pas, et ensuite avoir un contact particulier qui serait une boite vocale qu'il suffirait d'appeler.

- Transferts d'appels

Après lecture de la XEP correspondante à Jingle, il semblerait que ce soit possible lors de l'établissement de la session. Voir notamment l'exemple (http://www.xmpp.org/extensions/xep-0166.html#protocol-respon(...) ). C'était possible dans une ancienne version du protocole de rediriger un appel n'importe quand dans la conversation, mais ça ne semble plus être le cas.

- Conférences ? (ça je suis pas sur)
- Envoi de fax

Effectivement ces fonctions ne semblent pas être présentes dans Jabber. Mais pour l'envoi de fax, vu qu'on peut envoyer n'importe quel fichier avec Jabber, ça peut servir pour envoyer un fax.

- Gestion de la vidéo ...

C'est possible dans Jabber (cf http://www.xmpp.org/extensions/xep-0180.html ) mais je ne connais aucun client l'implémentant

Non, Jingle ne permet de faire que des choses très très basiques. SIP permet beaucoup plus, via un déluge de RFC.

Que permet de faire SIP que ne permet pas XMPP/Jingle ? Avoir beaucoup de RFC n'est pas vraiment un avantage en soi.

Jabber n'est pas un convertisseur multiprotocole ou je ne sais quoi.

En fait à la base si. Jeremie Miller a créé Jabber pour pouvoir parler avec ses contacts sous ICQ et ceux sous AIM. cf http://www.linux-mag.com/id/902

C'est pas que les développeurs de clients Jabber ont pas envie d'implémenter ce genre de fonctionnalité (les wizz seront dans la prochaine version de Spark il me semble), mais c'est juste que la plupart des clients ont un ou deux développeurs qui ne bossent pas à plein temps sur leur client, et qui n'ont donc pas le temps d'implémenter des fonctionnalités comme ça.

C'est pas tout, est-ce qu'on pourra discuter en vidéo à partir de Gtalk avec des personnes sur MSN ?

Tiens je savais pas que MSN avait changé son protocole pour passer à XMPP.

Si ce n'est pas le cas, alors tu ne peux pas discuter depuis GTalk avec les utilisateurs de MSN.

Oui il y'a les passerelles. Mais Google ne fournit pas de passerelle, donc tu es obligé d'utiliser les passerelles des autres serveurs ce qui est très mal vu car ça consomme des ressources aux niveaux du serveur, donc beaucoup d'admin empêchent de faire ça sur leur serveur.

De plus les passerelles ne supporteront jamais la voix/video, ou si elles le font, les admins désactiveront cette fonctionnalité, car ça voudra dire que toutes les communications passeront par le serveur Jabber puisque la passerelle devra convertir le flux en un truc lisible par MSN.

Bon je détourne un peu ce journal (honte à moi), pour faire de la pub pour le salon jabberfr@chat.jabberfr.org, qui est le salon officiel de ... JabberFR (la communauté francophone des utilisateurs de Jabber, http://www.jabberfr.org )

Ce salon est plutôt dédié pour ceux qui s'intéressent à Jabber, qui ont des problèmes avec Jabber, qui ont des questions sur son fonctionnement ... mais les sujets de conversations ne sont bien sur pas limités.

On peut aussi utiliser MUCkl (interface web) pour s'y connecter : http://chat.jabberfr.org/muckl_int/index.php?room=jabberfr (plus généralement pour tout les salons publiques de chat.jabberfr.org : http://chat.jabberfr.org/liste.php )

Cependant, la question que je me pose : Quel est l'intérêt de développer seul le serveur jabber14 alors que jabber2 existe et a une communauté autour de lui ? Le soucis que j'invoque ci-dessus pour bind n'a pas lieu dans le cas présent.

En fait jabberd2 a été en standby pendant assez longtemps. Et le développement semble reparti, mais je crois qu'il n'y aussi qu'une seule personne qui travaille dessus.

Et il faut aussi savoir que jabberd14 et jabberd2 sont totalement différents, et ils ne répondent pas toujours aux même besoin.

Pour l'instant aucun client (à ma connaissance) permet d'utiliser cette fonctionnalité, mais comme aucun serveur libre ne la gérait c'est pas vraiment étonnant, espérons que ca va se démocratiser, et que les clients commenceront à l'implémenter.

Pour le langage c'est principalement du C, certaines parties ont été réécrites récemment en C++.

Le problème c'est pas le support de Pubsub, mais le support de PEP (http://www.xmpp.org/extensions/xep-0163.html ) qui est une version simplifié de Pubsub, mais beaucoup plus intégrée au serveur, ce qui empêche de faire un composant externe comme Idavoll.

PEP pour un client n'est pas très compliqué, Psi gère ça très bien, et de manière assez claire pour l'utilisateur, genre une liste à cocher avec les notifications qu'on veut recevoir de cet utilisateur. Bon le problème c'est qu'il faut le faire pour chaque utilisateur, mais le client peut le faire tout seul.

Et ta tirade sur les développeurs est aussi ressorti à chaque fois... #@!$, chacun est libre de coder ce qu'il veut !

Pareil pour les serveurs, chacun est libre d'administrer ce qu'il veut. Si le serveur que tu utilise ferme ses passerelles, prends en un autre.

Tu es au courant que les passerelles sont pas facile à gérer pour les administrateurs ?

Ça bouffe pas mal de ressources, surtout quand des utilisateurs utilisent Jabber que pour les passerelles (ce qui est assez fréquent). De plus les protocoles propriétaires changent régulièrement, et ça oblige donc à faire des mises à jour forcés, vers des versions parfois moins stables. (déjà qu'en général les passerelles actuelles ne sont pas stables en version "stable", je te laisse imaginer ce que ça donne en version non stable).
Beaucoup d'utilisateurs préfèrent avoir un serveur plus stable et plus performant que d'avoir des passerelles.

Moi ce qui m'embête le plus avec les passerelles, c'est que si ceux qui les développent passaient leur temps à travailler que sur des fonctionnalités vraiment pour Jabber, ça attirerait plus d'utilisateurs et donc ça rendrait les passerelles inutiles. D'ailleurs c'est valable aussi pour les développeurs de clients pour les réseaux propriétaires.

Pour moi ce n'est pas une régression que de se tourner vers le futur. Les passerelles ont été créées pour aider Jabber à se développer, je suis pas sur que maintenant elles aident tellement sont développement, et serait plutôt un frein, surtout quand on voit le nombre de personnes qui utilisent Jabber sans savoir ce qu'est un contact Jabber. (par exemple : http://forum.jabberfr.org/viewtopic.php?pid=3698#p3698 )

Le changement d'état pour afficher la musique qu'on écoute est une débilité sans nom. Y'a un protocole pour faire ça défini dans la XEP-0118 ( http://www.xmpp.org/extensions/xep-0118.html ) et qui est bien plus propre.

L'affichage de la piste en cours dans le message d'état envoie des changements d'états assez souvent, ce qui peut :
* saturer le serveurs si tout le monde fait ça (enfin si y'a beaucoup d'utilisateurs)
* bouffe de la bande passante pour rien, surtout embêtant pour ceux qui utilisent Jabber sur un téléphone portable où ils paient au Ko
* est très énervant avec certains clients dans les discussions de groupe. En effet certain client (comme par défaut dans les anciennes versions de Gajim) affichent chaque changement d'état dans la fenêtre de discussions, ce qui est très énervant si le message d'état change souvent

La méthode préconisée par la XEP 0118 n'envoie le changement d'état qu'aux clients qui le veulent et pas à tout le monde. Bon y'a juste un problème c'est que le support au niveau des serveurs manque cruellement. Mais si y'a une forte demande, ça va s'implémenter plus vite dans les serveurs.
Psi gère déjà cette manière de faire.

Ce genre de jeux se prête à mon avis très bien à une implémentation utilisant Volity.

Pour ceux qui ne connaissent pas Volity, c'est une platforme pour créer et jouer à des jeux multijoueurs sur internet. Ca utilise SVG et JavaScript et surtout ca utilise Jabber/XMPP. Pour l'instant on peut jouer aux jeux Volity qu'avec le client officiel, mais comme c'est un projet libre, une implémentation dans des clients Jabber est possible.

* http://www.volity.net <- le site pour les utilisateurs
* http://www.volity.org <- le site pour les developpeurs

Jabberd2 ne semble plus développé, mais jabberd14 l'est toujours. Ce qui va d'ailleurs poser un problème de nom si une nouvelle version majeure de jabberd14 sort.

Le site de jabberd14 : http://jabberd.org

J'ai relu rapidement les deux accords : "Accord de service Microsoft" et "Déclaration de confidentialité en ligne Microsoft", j'ai rien trouvé indiquant qu'il faut avoir 18 ans.

Est-ce que tu aurais un lien montrant ca ?

Ca fait plus de 5 mois qu'une JEP sur la video par jabber existe : http://www.jabber.org/jeps/jep-0180.html et pourtant il n'en existe à ma connaissance aucune implémentation.

Ca fait 8 mois qu'une JEP existe pour l'audio par jabber, et il en existe que peu d'implémentations. Les choses commencent à bouger, mais c'est sur qu'avec plus de contributions aux clients, ca avancerait plus vite.

Le problème c'est le manque de développeurs. Si tout ceux qui développent pour un client pouvant se connecter à un réseau de messagerie instantannée propriétaire codaient des clients Jabber, on aurrait peut-être des clients plus matures, et avec plus de fonctionnalités.

Alors que MSN évolue avec des fonction interressante comme le partage dossier et sa synchronisation, les message différé, ou encore le control a distance d'un machine
* Partage de fichiers : http://www.jabber.org/jeps/jep-0135.html
* Controle à distance : http://www.jabber.org/jeps/jep-0146.html (bon d'accord c'est pas le controle à distance de la machine, mais du client, ce que je trouve à plus sa place dans un logiciel de MI.
* Messages différés : inclue dans XMPP, ca doit être dans la RFC 3921 http://www.xmpp.org/specs/rfc3920.html