Cette nouvelle version très attendue apporte beaucoup de nouveautés, notamment un support complet des RFC XMPP-Core et XMPP-IM, comprenant surtout les privacy lists qui permettent de manière très personnalisable de bloquer les communications avec d'autres utilisateurs, et une authentification possible avec SASL en utilisant jadc2s (un remplaçant pour le gestionnaire de connexion entre les clients et le serveur de jabberd14, jadc2s est maintenu par la même personne que jabberd14).
Beaucoup de ces nouvelles fonctionnalités permettent à jabberd14 de rattraper son retard envers ses « concurrents » libres : jabberd2, ejabberd et Wildfire, comme par exemple le support de l'internationalisation, et le support complet des RFC XMPP (Core et IM). Cependant, une des nouveautés n'existe pas chez ses concurrents, et pourtant elle pourrait s'avérer très pratique, elle permet de pouvoir sélectionner les messages non-lus que l'on souhaite récupérer depuis le serveur.
jabberd14 1.6.0 est déjà en place sur de nombreux serveurs, notamment amessage.de, jabber.ccc.de et swissjabber.ch qui font partie des plus gros serveurs européens. jabberd a été le premier serveur Jabber existant. Il a été développé au début par Jérémie Miller, l'inventeur du protocole Jabber en 1998, soit deux ans après ICQ et un an avant MSN Messenger et Yahoo! Messenger. Son développement a été chaotique ces dernières années, et aucune version majeure n'avait vu le jour depuis longtemps.
D'abord appelé juste "jabber", il a été renommé à jabberd pour éviter la confusion entre protocole, serveur et client qui régnait dans les débuts de Jabber. Depuis quelques années, une nouvelle version a été refaite à partir de zéro, et s'appelle jabberd2, l'ancienne branche ayant été renommée jabberd14, les deux projets étant indépendants et ne partagent pas de code.
Pour lever cette confusion, et alléger le nom du serveur, la prochaine version sera renommée, sûrement en « xmppd ».
Jabberd14 est pour l'instant développé par une seule personne, qui aurait bien besoin d'aide.
Aller plus loin
- jabberd14 (10 clics)
- Changelog (4 clics)
- JabberFr (5 clics)
- Jabber Software Foundation (2 clics)
# Sélectionner les messages hors lignes ?
Posté par Thomas Preud'homme . Évalué à 1.
Je suis curieux, quels clients permettent d'utiliser ces fonctionnalités ? Et sinon quel est le langage utilisé pour jabberd14 ?
[^] # Re: Sélectionner les messages hors lignes ?
Posté par François . Évalué à 3.
En suivant le 1er lien donné, on peut lire comme titre :
"jabberd14 – a Jabber server implemented in C/C++"
Je crois que cela répond à ta question ;-)
[^] # Re: Sélectionner les messages hors lignes ?
Posté par Omega (site web personnel) . Évalué à 5.
Pour le langage c'est principalement du C, certaines parties ont été réécrites récemment en C++.
[^] # Re: Sélectionner les messages hors lignes ?
Posté par Gof (site web personnel) . Évalué à 2.
(en plus, le protocole derrière est pas très joli)
[^] # Re: Sélectionner les messages hors lignes ?
Posté par tiennou_minet . Évalué à 6.
Ben quand tu t'absentes pour un mois parce que tu vas en vacances ou autre et que tu reconnectes pour la première fois, il peut arriver que tu reçoives un grand nombre de messages hors ligne et le client se fait flooder sans pouvoir rien dire :
- suivant le nombre, pas mal de clients plantent et tu perds tous tes messages ;
- même si le client ne plante pas, en général, tu te retrouve avec 350 fenêtres sur l'écran.
- si tu te connectes vite fait depuis un autre ordi que chez toi pour parler à quelqu'un vite fait tu n'as pas forcément le temps de lire tous tes messages mais tu ne veux pas non plus forcément les perdre.
C'est juste un exemple mais ça peut servir potentiellement à n'importe qui. En fait, le but est de permettre d'avoir un système de réception des messages plus fiable.
Le système actuel limite un peu l'usage des messages "hors ligne". La messagerie instantanée étant de plus en plus utilisée au dépend de l'e-mail, ce protocole aidera à aller plus dans ce sens. Après, ça dépend évidemment de l'utilisation de chacun.
Ca c'est subjectif...
# ça cause avec google talk ?
Posté par fasthm . Évalué à 1.
Donc j'utilise un compte google talk, est-ce que je peux parler avec des gens qui sont sous jabber ? Dans l'affirmative, comment dois-je procéder ?
(On avait bien dit que google talk ça utilisait jabber il y a quelques temps ?)
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: ça cause avec google talk ?
Posté par Gof (site web personnel) . Évalué à 4.
Le principe de Jabber est que les serveurs communiquent entre eux de manière totalement transparente pour l'utilisateur.
[^] # Re: ça cause avec google talk ?
Posté par madflo . Évalué à 5.
Mais plus précisément, Google Talk n'utilise pas vraiment Jabber (qui est une fondation). Les ingénieurs de Google ont réalisé un serveur compatible avec le protocole de transport de messages XMPP (Extensible Messaging and Presence Protocol).
Ils ont joué la carte de l'utilisation d'un standard créé par la communauté Jabber puis normalisé par les instances habituelles de l'Internet (IETF). En gros, ils ont joué la carte de l'interopérabilité, en supportant un protocole ouvert, et ça, c'est bien (en plus d'être dans l'esprit fondateur d'Internet) car tous les clients compatibles peuvent accéder au service. Et bien évidemment, je peux développer un client compatible pour <insérer ma plateforme obscure ici> si il n'en n'existe pas.
Et encore mieux, ils ont ouverts leurs serveurs au monde extérieur. C'est une success story des standards, je trouve ça plutôt beau.
# Wildfire
Posté par vrm (site web personnel) . Évalué à 1.
http://www.igniterealtime.org/blog/2006/12/19/scalability-tu(...)
# Association de ressources ?
Posté par Cyber Kobold (site web personnel) . Évalué à 2.
Par ci par là, on entend dire que les fonctionnalités n'arrivent pas à la hauteur de celles des concurrents.
Mais pourtant encore une fois (comme souvent avec les projets libres) les forces se dispersent dans 4 projets différents !
Pourquoi ne pas réunir tout cela en une seule équipe de dev et faire émerger enfin une solution réellement concurrente des MSN, Yahoo et ICQ. avec l'implémentation de toutes les recommandations ?
Il n'y a vraiment que dans la communauté du libre où on aime autant réinventer la roue
[^] # Re: Association de ressources ?
Posté par left . Évalué à 4.
[^] # Re: Association de ressources ?
Posté par madflo . Évalué à 2.
Personnellement, ça ne m'intéresse absolument pas d'opérer un serveur qui se mette à proposer autant de services qu'un client du type MSN ou Yahoo. A quoi pourrait me servir le centième des gadgets proposés ? Je veux juste profiter des fonctionnalités d'échange de messages avec des utilisateurs donnés et pouvoir visualiser leur statut.
C'est intéressant de faire une convergence des services (mettre l'audio au même endroit), mais il faut trouver une juste mesure entre l'outil pratique et l'usine à gaz (la vidéo, la prise de contrôle à distance...).
Je m'auto censure et ne dirait donc pas que je n'ai pas envie de voir les utilisateurs majoritaires des deux premiers services cités dans ton message abuser des ressources gracieusement mis à disposition par les particuliers et associations opérant des serveurs Jabber. Ca ferait vraiment trop élitiste. Pas bien.
[^] # Re: Association de ressources ?
Posté par Misc (site web personnel) . Évalué à 7.
> réinventer la roue
vraiment ?
j'ignorais que yahoo messenger + msn messenger + icq messenger + aol messenger, était soit du libre, soit exclus de la réinvention de la roue.
J'ignorais aussi que les 45 types de jeux différents de stratégie, de fps, de foot et autres mutualisent grandement le code. Que nombreuses bases de données proprios ( oracle, sybase, sqlserver ) faisaient de même, tout comme les nombreux constructeurs de hardware.
[^] # Re: Association de ressources ?
Posté par Dring . Évalué à -1.
[^] # Re: Association de ressources ?
Posté par Gniarf . Évalué à 5.
les bons réinventeurs de la roue, ils font de la concurrence aux inventeurs de la roue. c'est bon pour le marché et ça encourage l'innovation !
les mauvais réinventeurs de la roue, ils gaspillent leurs efforts ! ils refont la même chose que les autres mais en plus nul et toujours avec un métro de retard, sauf en général pour les idées à la con qu'il aurait justement fallu ne pas copier.
c'est vrai que pour l'oeil pas très exercé, la différence est subtile.
[^] # Re: Association de ressources ?
Posté par Maxime (site web personnel) . Évalué à 7.
Donc tu aurais du critiquer le fait qu'il existe des dizaines de clients jabber différent.
A quoi sert la diversité des serveurs ?
Certains ont priviligié la monté en charge, d'autres l'administration facile, d'autres la facilité de programmation du serveur etc...
Bref 4 ce n'est pas trop. Mais je suis d'accord il n'en faudrai pas plus quand même.
A quoi sert la diversité des clients ?
Je pourrai répondre par : à quoi ca sert d'avoir 36milles clients mails différents ? Pour les même raison que pour les clients Jabber : Répondre à des besoins différents.
J'ai envie d'avoir un truc fonctionnel, je m'en fous de l'audio et de la video. D'autres veulent des wizz, des smileys de 50px de coté etc...
Je veux pouvoir parler à des enfants sans avoir à supporter d'attroces couleurs par exemple. Et sans avoir à les forcer de changer de logiciel.
La diversité c'est justement une force de Jabber. Ce qui est important c'est le développement de librairies jabber permettant de coder rapidement un client sans trop réinventer la roue.
[^] # Re: Association de ressources ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est bien pareil pour jabber. Un seul serveur est une mauvaise idée. Beaucoup trop dangeureux. Je pense que le minimum est d'avoir trois implémentations qui tiennent la route.
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.
[^] # Re: Association de ressources ?
Posté par Omega (site web personnel) . Évalué à 4.
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.
# La vidéo ?
Posté par Jeanuel (site web personnel) . Évalué à 1.
Kopete prend bien en charge ma webcam, mais pour quoi faire ?
[^] # Re: La vidéo ?
Posté par nonas . Évalué à 2.
[^] # Re: La vidéo ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Pour Jabber, d'apres Gof (qui interviendra peut-etre), c'est pas tres évident a implementer... mais il est sur le coup apperemment.
[^] # Re: La vidéo ?
Posté par Gof (site web personnel) . Évalué à 3.
J'ai peut-être dit que ça prendrais un peu de temps. Jingle est assez complet, et donc forcément il faut un peu de temps pour implémenter tout.
Mais dans KDE4 ce sera probablement possible
Sinon, (en exclusivité), pour utiliser la aujourd'hui webcam avec jabber dans Kopete, il suffit d'appliquer ce patch aux sources de Kopete 0.12 . (et il faudra que votre correspondant fasse de même)
http://bepointbe.be/jabber_webcam2.diff
(Note: ce patch a été fait en une soirée en vitesse, c'est pas standard du tout, et ce ne sera pas dans aucune version officielle de Kopete.)
[^] # Re: La vidéo ?
Posté par Jeanuel (site web personnel) . Évalué à -1.
Merci bien mais... nous n'avons pas les mêmes valeurs. Il y a une alternative ? (genre un solft déjà compilté qui le ferait ?)
[^] # Re: La vidéo ?
Posté par Jeanuel (site web personnel) . Évalué à 2.
Sur le fond, c'est très bien. Et encore merci à ceux dont Golf, visiblement, qui travaillent à faire que ça marche aussi pour moi.
[^] # Re: La vidéo ?
Posté par Maxime (site web personnel) . Évalué à 2.
Et si non, ça en est où ?
Et pour l'implémentation de jingle dans kopete, ça en est où ? Est-ce stable ou aussi plantogène que psi compilé avec jingle ?
[^] # Re: La vidéo ?
Posté par Gof (site web personnel) . Évalué à 3.
Quand à l'implémentation de jingle dans Kopete : oui, c'est toujours aussi plantogène que psi compilé avec jingle :-) (le même code est utilisé : la libjingle de google, qui contient pas mal de bugs)
Normalement, libjingle ne devrais plus être utilisé dans KDE4
[^] # Re: La vidéo ?
Posté par Maxime (site web personnel) . Évalué à 2.
J'espère (depuis trop de temps sans doute...) que le développement de Jabber va vraiment s'accélerer.
A ce sujet, ca serai cool que Google mette un peu plus de moyen dans le développement de leur logiciel... Non parce qu'il gere toujours pas les MUC ni les groupes de contact... C'est un peu la honte ca...
[^] # Re: La vidéo ?
Posté par Juke (site web personnel) . Évalué à 2.
[^] # Re: La vidéo ?
Posté par Nÿco (site web personnel) . Évalué à 3.
Parceque SIP est mauvais au niveau des NAT. Jingle va se servir de ICE, méthode qui devrait résourdre 99,9% des problèmes liés aux NAT.
Intégration
Et puis parceque SIP et Jabber n'ont rien à voir et que Jingle et Jabber sont super bien intégrés (normal, Jingle est développé et standardisé par la communauté XMPP/Jabber).
Mais il existe aujourd'hui plusieurs implémentations logiciels bicéphales de type softhpone SIP ET client Jabber :
- WengoPhone, libre, C/C++
- Gizmo Project, proprio, C/C++
- SIP Communicator, libre, Java, version alpha
- ...
[^] # Re: La vidéo ?
Posté par M . Évalué à 2.
Heu avec Stun, j'ai jamais vu de pb.
[^] # Re: La vidéo ?
Posté par left . Évalué à 2.
veinard ;)
# Solutions Linux: Conférence dédiée à l'IM et la VoIP
Posté par Mickaël Rémond (site web personnel) . Évalué à 2.
J'en profites pour annoncer, pour ceux que le thème intéresse à titre professionnel, qu'une session de conférence sur le sujet aura lieu sur le salon solutions Linux 2007.
La session dure une journée complète et se déroule en deux parties:
http://www.solutionslinux.fr/fr/conferences_detail.php?id_co(...)
http://www.solutionslinux.fr/fr/conferences_detail.php?id_co(...)
Le programme promet d'être très intéressant:
- Loïc Bernable: Le point sur la voix sur IP
- Mickaël Rémond, Process-one: Le point sur la messagerie instantanée Jabber/XMPP
- Christophe Villemer, Agence universitaire de la Francophonie,
Dynamiser la communication interne et réduire les coûts au sein d'une organisation internationale grâce à Jabber et Asterisk
- Jérome Wagner , Wengo: WengoPhone, une brique essentielle pour une architecture de communication sur IP ouverte.
- Sylvain Boily, Proformatique: Asterisk, le PABX libre
- Sébastien Louyot, Galop Télécom (Intervention à confirmer): Utilisation de SER en milieu télécom : une preuve de la robustesse des projets libres dans le monde de la VoIP
- Walid Nouh, AtosOrigin et Nicolas Vérité: Présentation des clients de messageries instantanée Jabber.
- Jérôme Sautret, Process-one: ejabberd, architecture et mise en oeuvre d'un serveur de messagerie instantanée haute-performance.
Voilà. Nous serions ravi de vous rencontrer là bas (durant les conférences ou sur le salon).
Mickaël
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.