Nÿco a écrit 3599 commentaires

Google est un poids lourd, en effet, il pourrait bien faire basculer le monde vers XMPP.

Justin Uberti, un développeur de Google Video Chat répond à ce blog-post ici :
http://blog.senko.net/2008/11/12/gmail-videochat-the-good-th(...)

C'est juste de a signalisation à changer.

iChat est proprio et utilise ses propres extensions/protocoles proprios et spécifiques pour faire de la voix/vidéo par dessus XMPP. Donc c'est incompatible et non-interopérable avec le reste du monde.

> Google n'utilise pas Jingle de la XSF

Oui, mais...

>> Dès que la spécification Jingle sera stable, Google implémentera cette version.

En même temps, écrire des specs, pour la plupart des gens, c'est juste chiant et trop balaise.

D'un autre côté, il est bien impliqué dans l'IETF, ce qui permet beaucoup de « reuse », important dans le monde des standards ouverts. Exemples : TLS, SASL, ICE (STUN, TURN), xTLS...

Tu as oublié toutes les versions mobiles, véritables catastrophes...

Oui, je suis d'accord, c'est un SPOF et ne veut/sait pas déléguer.

Les spécifications de XMPP sont étudiées et validées par un conseil élu par les membres de la XSF, mais soumises et travaillées et amont par des auteurs de spécifications et des développeurs. Tout feeback est possible à tout moment. On a ici un mode cathédralo-bazaar.

Les innovations sont encouragées, car XMPP est conçu extensible, libre à toi d'adopter la méthode que tu veux : tout seul dans ton coin et publication une fois stable à ton goût (rapide), ou directement au sein de la communauté avec un processus collaboratif de revue (long, mais fiable).

Le « Firefox de la messagerie instantanée » est difficile à définir, mais les points qui fait consensus, c'est son succès face aux propriétaires, et sa promotion des standards ouverts.

Tu ne trouves pas où et comment contribuer sans faire de code ? Cool, on a besoin de toi, fais un tour sur :
http://wiki.jabberfr.org/
http://forum.jabberfr.org/
xmpp:jabberfr@chat.jabberfr.org?join
http://xmpp.org/about/discuss.shtml

Je n'ai jamais parlé de coder, mais seulement contribuer, tu ne sais pas lire, ou tu lis mal, dommage.

Oui, tu te plains, comme tout le monde ou presque ici, c'est triste, mais où as-tu contribué ? (pas du code, je dois préciser maintenant...) Je suppose que non, comme tous les donneurs de leçons ici.

Si ta seule référence est MSN, alors c'est bien triste pour toi, mais par exemple ce que tu peux apporter, c'est une liste de ce qu'il manque à ton client préféré, par rapport à MSN. Et tu la soumets aux développeurs, mais stp en adoptant profil bas, car eux bossent en permanence sur leur soft, ne pas débarquer en m'as-tu-vu. OK ?

Mais avant, fais bien attention de bien maîtriser ce dont XMPP est capable : http://wiki.jabberfr.org/Cat%C3%A9gorie:Fonctionnalit%C3%A9_(...)

Il faut aussi ajouter que l'écriture d'une spec prend du temps, beaucoup de temps, est-ce que vous pouvez vous rendre compte de celà ?

Il s'agit d'un standard ouvert donc hyper important, il ne faut absolument pas se louper, il faut que ce soit nickel, la spec n'étant qu'un (presque) début d'un processus long de plusieurs années souvent : naissance de l'idée, discussions autour de cette idée, les besoins, l'imbrication dans l'existant, ensuite concrétisation de l'idée par le brouillon de spec, révisions de la spec, implémentations diverses dans des clients/serveurs/bibliothèques, retours d'expérience qui vont à leur tour modifier et affiner la spec, de manière cyclique, jusqu'à l'obtention d'un consensus.

Celà dit, l'écriture des specs XMPP sont très rapides comparé à l'écriture de specs de standards ouverts en général. Ceci est dû au fait que la communauté est très centrée autour de la XSF qui catalyse ce développement.

Tout à fait d'accord...

As-tu un moyen de (dé)montrer le côté pratique de ces « horloges » ? J'ai déjà tenté dans les ML de la XSF, mais sans succès... D'une part, il y a le côté serveur à modifier pour « tagguer » chaque message, d'autre part le GUI du client. Côté serveur, ça sera dans une XEP, côté client, à la charge des développeurs.

Autre chose, il y a deux types de conversations : dans une chatroom/MUC, ou un à un. Dans un MUC, pas de soucis car c'est le serveur de MUC qui détient l'horloge « atomique » (disons » de référence »), mais dans le cas d'un conversation un à un pour deux utilisateurs sur deux serveurs différents, quelle entité gère cette horloge de référence ?

Si tu t'amènes avec un brouillon de XEP déjà avancé, tu auras beaucoup plus de chances que ça passe. Si tu as besoin, j'y contribue !

http://trac.gajim.org/ticket/3927
Avec des « moi je » on ne fait pas avancer un soft. Trouve d'autres gens qui en ont besoin, essaie de convaincre les devs (genre de sujet déjà évoqué pour ma part avec eux), écris des spécifications, crée des maquettes de GUI... Il te reste encore tout plein d'autres choses à faire, bigrement plus constructives que juste aller te plaindre sur Linuxfr (que les dev de Gajim ne liront sans doute jamais).

URL ?

Tout le monde a le niveau pour tester et rapporter d'éventuels dysfonctionnements dans les chatrooms des projets.

En gros, il nous manque - effectivement - un Firefox de la messagerie instantanée : un soft libre, qui rassemble et perce en terme de « parts de marché » (je n'entrerais pas dans le jeu des qualificatifs, souvent subjectifs donc sujets à trolls).

Une des raisons de base, c'est que la philosophie Jabber, c'est « complexité sur le serveur, pas sur le client », donc on a vu et on voit régulièrement des petits clietns tous simples à profusion, mais rien de vraiment complet ni « killer ».

> * possibilité de mettre dans la tray icon le salon (et pas juste la liste des rosters) ;

Ça servirait à quoi ? Comment tu imagines la GUI ?

Tu as essayé toutes les GUI, type mono-fenêtrée Gajim, OneTeam, Tkabber ou SamePlace ?

> * facilité d'administration (bien que certains logiciels comment jabbim en soient pourvus) ;

Gajim, Psi, Coccinella, Spark aussi...

> * possibilité de se connecter à un salon sans avoir de compte (juste en choisissant un pseudo à la volée comme muckl)

Ça servirait à quoi ?

Parle de ça sur la ML "standards" : mailto:jdev-subscribe@jabber.org archives http://mail.jabber.org/pipermail/jdev/
La XEP MUC : http://xmpp.org/extensions/xep-0045.html

> PubSub, défini par Nyco comme le "RSS de la messagerie instantanée"

Oh mon dieu, que c'est réducteur ! Tu as un mécanisme complet de droits et les notifications instantanées par push (pas de polling consommateur en ressources), pour faire court...

> Quant à jingle n'en parlons pas, aucune idée de ce que ça devient,

Si tu n'en as aucune idée, c'est parceque tu ne suis pas : http://xmpp.org/extensions/xep-0166.html#revs la XEP est activement développée ! Il y a aussi ICE de l'IETF.

Sur http://xmpp.org/extensions/ trouveras toutes les XEP relatives à Jingle : voix, vidéo, ICE (NAT), transfert de fichiers...



Mais puisque tout le monde (ici-bas sur Linuxfr) maîtrise si bien les besoins des users grand public, et donne des leçons en permanence, râlent en permanence sur Jabber, pourquoi tout ce petit monde ne contribue pas à Gajim, Psi, Coccinella, SamePlace, Jabbim, JWChat, Ajaxbber et autres ? http://wiki.jabberfr.org/Clients
Kopete/Adium et Pidgin, des clients libres multiprotocoles en ont sacrément besoin du côté de Jabber/XMPP !

> De plus, c'est pas pour troller, Zimbra c'est un pas du vrai libre,

1/ Qu'entends-tu par « pas du vrai libre » ? Peux-tu argumenter stp ?

2/ Et qu'est-ce qui te permet d'éventuellement dire que OBM est du « vrai » libre ? Peux-tu argumenter stp ?

(au final, peux-tu faire une brève comparaison stp ?)

> y a t il possibilité de faire un billet sur Zimbra [...] ?

Pourquoi tu poses la question ? http://linuxfr.org/submit.html

> OBM ne fait pas tout ce que fait Zimbra et Zimbra ne fait pas tout ce que fait OBM

Tu peux détailler stp ?

Il est dit sur http://obm.org/doku.php?id=obm_features que OBM intègre Jabber/XMPP, or sur la démo à http://obm-demo.aliasource.fr/ je ne trouve pas l'IM, où est-il ? J'ai loupé un truc ?

Si on cherche sur tout le site "xmpp" on ne trouve rien http://www.google.fr/search?q=site%3Aobm.org+xmpp et "jabber" que la page citée plus haut http://www.google.fr/search?q=site%3Aobm.org+jabber

Pourquoi t'arrêter ?

Au lieu de penser API, il faut penser format d'échange. Voire protocole...

Il est peut-être nécessaire que la communauté forge se bouge un peu sur des formats d'échanges de trackers, code source, forums, ML, wiki et tous les services qu'on trouve dans les forges, en pensant bien aux correspondances entre les ID des objets des deux côtés de l'échange, mais aussi aux liens avec les autres services (lien bug-commit par exemple).

> C'est plus qu'un guide qu'il faut, c'est des applications "setup" "next" "next" "start encoding" "finish" "thanks" "à demain" qui pondent un truc bien du premier coup!

...voire l'encodeur directement dans le navigateur ?

La bibliothèque Schrodinger implémentant Dirac est sans doute un peu lourde pour un navigateur ? On déportera alors avantageusement l'affichage de la vidéo dans un lecteur externe...

> Alors on peut faire un dépêche avec si peu de texte? Si j'avais su...

Tout à fait. Mais il est vrai que la taille de la dépêche fait souvent l'objet de débats en modération.

En fait, on tente d'encourager à proposer des news « complètes », mais c'est souvent effectivement difficile devant une case (page) blanche.

Derrière, on corrige s'il y a besoin, et éventuellement on étoffe si on trouve des infos utiles à ajouter.

Vos contributions sont les infos que vous retrouverez sur le site, vous êtes encouragés.

En général, la politique de rétention à adopter est proche de celle du courriel. Donc va voir les mecs qui s'en occupent.

De même pour le nommage des serveurs :
* @company.com
* @direction.company.com (direction ou unité ou entité)
* @localisation.company.com