Omega a écrit 104 commentaires

Sinon tu peux regarder du coté de Hello Asso, en gros y'a pas de frais mais ils incitent les gens qui donnent à faire en plus un don à Hello Asso. Et tu peux faire des dons récurrents ou non.

Psi ne te force pas à utiliser la zone de notifications, si tu décoches la case use docklet dans la configuration du logiciel il se comportera comme tu le souhaites, à savoir il se fermera vraiment en fermant la liste de contact.

Et s'ils utilisent deux messagerie en même temps, on perd l'argument de ne pas utiliser msn car c'est pas bien.

Perso je m'en fous que mes contacts utilisent MSN en plus de Jabber, ils font ce qu'ils veulent. Tout ce que je veux c'est pouvoir leur parler d'une manière ouverte, donc qu'ils ne m'imposent pas un logiciel pour discuter avec eux.

Tu aimerais devoir utiliser un client et un compte particulier pour leur envoyer des mails pour la seule raison qu'ils utilisent un serveur ne supportant pas les protocoles standards ?

Bref, il faut reconnaître que c'est quand même beaucoup moins du minitel 2.0 que jabber où les avatars sont stockés sur le serveur

En fait avec la nouvelle spec pour les avatars rien ne t'oblige de les stocker sur le serveur Jabber, tu peux le stocker sur n'importe quel serveur HTTP, ou sur un autre serveur Jabber que le tiens : http://xmpp.org/extensions/xep-0084.html#process-pubdata

C'est quoi ce nouveau logo ? Il n'allait pas bien l'ancien ? Parce que bon un bête tux c'est pas très original.

Avez-vous vu le screenshot d'Empathy avec une carte du monde (avec libchamplain) pour montrer les contacts au lieu d'une liste?
Non. On peut voir ça où ? Ca à l'air intéressant.

Ca dépend quelles specs, des trucs du genre http://xmpp.org/extensions/xep-0245.html n'importe qui peut les écrire.

En même temps, sans Peter Saint-André, je doute que le protocole soit aussi avancé que ce qu'il est maintenant.
Je ne sais pas, c'est une question que je me suis souvent posé. Personnellement je pense qu'on se repose trop sur lui pour faire des specs et que s'il n'avait pas été là plus de personnes se motiveraient pour écrire ces specs.

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.

Sauf qu'au final la plupart des specs sont écrites par Peter Saint-André, ce qui pour moi est vraiment un gros problème. D'accord il est payé pour faire ça, mais le jour où Jabber, Inc. Cisco ne veut plus le payer ça va ralentir encore plus le processus.

En fait les XEP avancent selon les motivations de gens qui les écrivent, et aussi selon la complexité de celles ci. Si la personne qui écrit la spec pousse pour que ça se passe plus vite.

D'après le processus de validation des XEP [http://xmpp.org/extensions/xep-0001.html] une XEP peut passer au statut draft vite (en une vingtaine de jours) si personne n'a d'objection. Et même s'il y'a des objections, si la personne qui a écrit la spec la met à jour rapidement pour corriger les problèmes évoqués, ça peut quand même aller vite.

Quand les XEP sont en draft (brouillon) en fait ça veut dire qu'elles sont grosso modo matures et que plus de gros changements seront fait. Après c'est vrai qu'ils peuvent rester longtemps à cet état, mais c'est pas vraiment un problème, tant qu'elles ne sont plus au statut expérimental.

Pour la XEP sur les émoticones tu dois parler de la XEP 38 [http://xmpp.org/extensions/xep-0038.html], elle n'a pas été mise à jour et a donc été "deferred". Elle est au final pas très bien faite, puisqu'elle permet juste de préciser un jeu d'icône lorsque tu envois un message, le correspondant devant disposer de ce jeu d'icône pour pouvoir afficher correctement le message. Il faudrait plutôt une technique pour envoyer les emoticones quand la personne ne l'a pas.

Rien n'empêche aux développeurs de documenter les choses non standards qu'ils font avec leur client. D'ailleurs c'est pour moi un des problèmes de XMPP, ceux qui font les clients ne veulent pas sortir du protocole, et attendent donc sur ceux qui font les specs, et ceux qui font les specs les font sans avoir testé d'implémentation avant, ce qui donne des specs pas forcément très adaptées du premier coup.

Du coup les specs mettent du temps à murir, et les devs sont frilleux et attendent d'avoir des specs en version finale pour commencer à les implémenter, ce qui retarde encore plus leur apparations.

Aucun des messages que tu ne cites ici ne provient d'admin du serveur (à part le lien du blog de Lucas, mais il dit bien ce qu'il veut sur son blog, et soit dit en passant ce qu'il a dit est tout à fait vrai, beaucoup d'utilisateurs de Mac n'utilisent le serveur que pour pouvoir utiliser MSN avec iChat). je trouve ça un peu simpliste de critiquer les admins parce qu'une personne (ce n'est même pas un utilisateur du serveur) est parti en croisade contre les passerelles.

Pour moi le sondage sur les passerelles montre bien qu'on ne prend pas les discussions comme ça sur un coup de tête, le sondage montre bien que les passerelles ne sont pas désirés [http://wiki.jabberfr.org/Apinc:Meeting4#Autres_passerelles_:(...)].

Je trouve ça quand même facile d'attaquer personnellement quelqu'un (oui quand tu parles des admins rois je me sens visé) et après dès qu'on essaie d'aller un peu plus loin dans la discussion de dire "la discussion est close".

Je suis un des « admins rois qui te font vomir », donc ma prose risque d'être un peu orienté.

Le problème s'est que personne (à part les admins et 2 ou 3 geeks s'accouplant entre eux) n'avait plus de 3 ou 4 contacts jabber sur sa liste.
C'est pas ce que dise mes stats, ceux qui utilisent la passerelle en général n'ont en effet que peu de contacts jabber, mais la majorité des gens n'utilisent pas de passerelle.

Au bout de deux semaines, c'était la guerre sur le forum : les utilisateurs s'impatientaient et les admins crachaient sur la gueule de tous ceux qui osaient se connecter un autre protocole que jabber en les faisant passer pour des suppôts de Satan.
Tu n'aurais pas des liens, non ? C'est un peu facile de dire qu'on est les grands méchants en ne donnant aucune indication pour retrouver ces discussions (même pas de date approximative).

Troisième semaine, la nouvelle tombait comme une bombe : les passerelles étaient définitivement mises à la benne. Les admins jubilaient, les utilisateurs râlaient, et au final tout le monde avait perdu.
Ah c'était de la fiction, ça explique pourquoi je ne me rappelais pas de cette histoire. Les passerelles n'ont pas été arrêté pour le moment (je dis pas que ça n'arrivera pas, hein).

Perso, j'ai vite abandonné mon adresse jabber.fr (ces "admins rois" m'avaient donné envi de vomir) pour utiliser mon adresse gmail comme tout le monde et en me retournant vers une solution logicielle multiprotocolaire open source (Pidgin).
C'est sur que gmail pour les passerelles c'est mieux. Tu aurais du penser à Pidgin plus tôt.

Enfin, il y a les maitres à bord qui ne respectent plus rien même plus leurs motivations initiales (ici il s'gissait de promouvoir jabber et, n'en déplaise à certain, l'intéropérabilité est une des clés), tout ça pour au final juste avoir raison ? Ou moins se faire chier ?
Les passerelles ce n'est pas de l'interopérabilité, c'est de la compatibilité, et je n'ai jamais vu d'étude prouvant que cette compatibilité était bénéfique pour Jabber, personnellement j'aurais plutôt tendance à penser le contraire (les gens utilisant les passerelles ayant tendance à cacher le fait qu'ils utilisent Jabber à leur correspondant, ne faisant pas marcher l'effet de réseau). Enfin si tu as des liens pouvant éclairer ma lanterne je suis toujours preneur.

Et pour moi l'argument « Moins se faire chier » est un argument tout à fait valable pour des bénévoles, notre temps n'est pas extensible à l'infini, on a aussi une vie professionnelle et privée en dehors de l'administration du serveur jabber, et des fois on ne peut plus faire tout ce qu'on a à faire.

Après désolé si les admins ne font pas toujours ce que toi tu penses être le mieux, mais je pense pas qu'on soit des « rois » comme tu dis. Déjà on passe beaucoup de temps à administrer le serveur, on a peu de gratitude en retour (on entend plus souvent les raleurs que les gens contents, mais bon c'est pas vraiment grave), et des fois on doit faire des choix, que ce soit technique ou moral, qui ne plaisent pas forcément à tout le monde, mais on essaie toujours d'expliquer au mieux nos choix et on est toujours ouvert à la discussion (je rappelle qu'on fait régulièrement des réunions publiques ou tout le monde peut venir parler, et j'ai toujours répondu aux gens qui voulaient me parler du serveur, que ce soit en bien ou en mal).

> Le problème ne viendrait-il pas de l'évolution du standard XMPP et de ses extensions?
> Je conçois qu'XMPP est un standard où tout est mûrement réfléchi, mais est-ce vraiment efficace au fond, d'être aussi long?
> - on voit quand même des extensions remplacer d'autres extensions "parce qu'elles sont mieux", ou corriger des erreurs
En presque dix ans les besoins et les approches changent, la technologie XMPP s'améliore, ce n'est donc pas vraiment étonnant que certaines extensions soient changées par des nouvelles. Après des fois c'est peut-être pas toujours très jusitifié, c'est vrai.

> - on a plusieurs extensions qui proposent des solutions alternatives à la résolution du même problème ; oui, le libre, c'est le choix, mais bonjour pour les développeurs
Même problème, ils ont été fait à des moments différents, ou pire encore par des gens différents. Par exemple la technique la plus courante pour les avatars utilisent un truc très moche qui consiste à mettre dans chaque message de présence un hash de l'avatar. Cette technique a été faite par Apple pour iChat, la XSF a standardisé cette méthode dans un XEP informationnel, alors que pendant ce temps là elle poussait l'utilisation de PubSub, qui a l'époque était pas encore mur sur les serveurs, ce qui fait que maintenant la plupart des clients utilisent la technique iChat.

Donc oui c'est regréttable, pour moi ça vient de PubSub qui est beaucoup trop complexe, ils ont voulu faire un truc qui fasse trop de chose, alors qu'ils auraient du commencer par un truc plus simple, quitte à faire évoluer le standard par la suite.

> - pendant ce temps, un certain Google fait son API à sa sauce, et on se retrouve à essayer de courir après

Google n'a fait que Jingle (et deux trois extensions très mineures), et Google a participé au groupe de travail jingle pour standardisé ça, donc on ne peut pas dire qu'on court derrière au niveau du standard.

Après la XSF est un organisme ouvert, rien n'empèche n'importe qui de participer au décisions, et même d'être élu pour pouvoir voter pour les standards autour de Jabber.

En fait pour moi le gros problème c'est que les clients attendent toujours les XEP de la XSF plutôt que de faire eux même des essais et de proposer des extensions. Là en général on a des extensions avant d'avoir des implémentations, donc il n'y a même pas d'implémentation de référence pour pouvoir tester sa propre implémentation.

Ah ben ça tombe bien, la version de dev de psi à le tableau blanc inclus depuis une semaine, et ça marche plutôt bien. On peut donc vraisemblablement espérer voir ça arriver lors de la prochaine sortie de psi.

> Alors, 1, est-ce que je me trompe ?
Oui c'était pas l'été 2004 mais décembre 2005, mais oui ça change rien au fait que ça commence à dater.

>2 est-ce que ça n’intéresse pas plus les développeurs que les onglets détachables dans les fenêtres MUC, par exemple (ce qui m’étonnerait, car pour moi, c’est bien LA killer feature manquante) ? Ou bien est-ce que les dev attendent quelque chose qui ne dépend pas d’eux (finalisation de la norme, ou que sais-je).
Je pense que tous les devs de clients Jabber aimeraient bien avoir Jingle dans leur client, mais le problème c'est que le passage des NAT est assez compliqué, Jingle recommande l'usage de ICE [http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ(...)], mais ICE n'est pas encore une RFC et n'est pas encore tout à fait finalisé. De plus les XEP jingle ne sont pas non plus totalement finalisées, mais ça devrait venir assez vite, la XSF travaille beaucoup dessus.

> Enfin 3, est-ce qu’il y aurait d’autres projets qui auraient implanté jingle sans qu’on en parle pendant ce temps ?
Si. Il y'a déjà Empathy [http://live.gnome.org/Empathy] qui permet d'utiliser la voix et la vidéo par Jabber. Sinon Gajim a eu une branche avece Jingle (pour la voix seulement il me semble, mais bon si la couche de transport est implémenté le reste n'est plus trop dur à faire pour rajouter la vidéo), mais les devs de Gajim attentent la finalisation de la norme Jingle pour mettre ça dans la branche principale. Sip communicator gère aussi Jingle pour la voix.

Le problème qu'on va avoir c'est la compatibilité entre tous ces clients, car certains se basent sur les premières versions du protocole, d'autres sur des versions plus récentes, et bien sur elles ne sont pas tout à fait compatible entre elles. Pour compléxifié l'affaire Google Talk utilise aussi une version de Jingle à leur sauce. Enfin on peut espérer que lorsque la norme sera finalisé, les clients vont homogénéiser un peu tout ça.

Sauf que gérer le système de paiement est différent que de gérer l'infrastructure complète du site.

Pas comme si un certain omega avait dit que jingle était l'équivalent de SIP, et ce pour transmettre la vidéo.
Et ? L'équivalent de SIP ça voulait bien sur dire pour la signalisation, fait pas comme si tu ne comprenais pas .

tu ne crois quand même pas qu'avec Jingle les données passent par XMPP ?
Moi je crois rien. Par contre toi tu as dis pas mal de truc allant dans ce sens.
par exemple, je te cite :

et permet de faire de la voix et de la visio par jabber.
Remettons cette citation dans le contexte, c'était au début du thread et ce n'était pas technique du tout, je vulgarisais les choses. J'aurais certes pu écrire :
> Jingle permet d'initier une communication vidéo et voix avec une autre personne en transmettant les données sur un flux RTP
Mais ça aurait apporté quoi de plus à ce moment de la discussion ?


Mais dire que jabber remplis les même fonction que SIP (j'ai utilisé jabber explicitement pour marquer que tu en parle d'un point de vue de protocole, vu que tu le compare à SIP)
(je te cite)
>Perso je vois pas ce que SIP apporte de plus que Jabber, à part la complexité.
alors que c'est faux par ex ...
Je donne mon avis ? J'ai pas le droit ? Moi non plus je suis pas expert partout, et je ne suis certainement pas expert en SIP, même si je semble le connaitre mieux que toi tu ne connais XMPP/Jingle. N'empèche que je n'ai encore vu aucun argument rédhibitoire contre Jingle, à part les "personne ne l'utilise", bref le même genre d'argument qu'utilisent les MSNiens contre Jabber, ou encore les gens contre IPv6.

Tu veux comparer un protocole déja normalisé, d'un protocole que tu dis qu'on peut étendre itou, et ce au niveau fonctionnalité ?
Parce que SIP ne peut pas être étendu ? Arrête de te foutre de ma gueule.


>C'est juste un champs utilisé par DiffServ ça. (mais on diverge)
C'est juste un champ dans IP. Ca peut etre utilisé par diffserv ou autre.
Dans IP il s'appelle TOS, mais c'est pas grave [http://www.faqs.org/rfcs/rfc791.html].

>Donc tu ne répondais pas à mon objection qui disait que le protocole est compliqué, je m'en tape qu'il existe une lib l'implémentant.
T'a raison, des qu'on souhaite utiliser un protocole, on essaie toujours de se faire la stack avant de voir si il existe déjà une librairie qui pourrait répondre a ses besoins.
Arrête de faire semblant de pas comprendre ce que je raconte, c'est fatiguant à la longue. C'est par parce qu'une lib existe que le protocole est moins compliqué. Certes pour une personne souhaitant l'implémenter c'est moins compliqué, mais la lib ne peut pas être utilisé partout, ni dans tous les cas.

Effectivement tu parles sans rien savoir, c'est un peu usant. Tu ne crois quand même pas qu'avec Jingle les données passent par XMPP ? Heureusement que ça passe en dehors du flux XMPP, sinon les pauvres serveurs morflerait, bref ça passe comme SIP en RTP.

on dit "il est préférable de passer par sip pour la vidéo" et on répond "pas besoin , jingle est déjà un équivalent de SIP pour jabber"
Le gars il dit que la VoIP/Visio est impossible sans utilisé SIP, on lui répond que c'est faux, il existe des clients l'implémentant, et toi tu montes au créneau comme quoi on veut remplacer SIP partout par XMPP ? On doit pas avoir la même compréhension du français.

Perso je vois pas l'intérêt dans un client supportant déjà XMPP de devoir rajouter une pile SIP. Surtout qu'il faudrait aussi rajouter un serveur SIP synchronisé avec le serveur Jabber, bref tout un bordel juste pour pouvoir faire de la VoIP et de la visio entre deux clients de MI ? Désolé si je trouve ça débile.

>On parle du protocole là, pas des implémentations.
Si tu préfère "les implémentations existantes avec SIP permettent de faire ça, tandis que les implémentations existantes avec jingle ne le permette pas."
Et ? Moi je parle du protocole depuis le début, pas des implémentations. J'essaie juste de comparer Jingle et SIP au niveau du protocole.

>J'ai dit ça où ?
la par exemple
>Et on peut faire de la QoS sans ça de toutes façons.
On doit pas parler la même langue. Si on peut le faire autrement ça veut dire que la première méthode ne sert à rien ? Je dis juste que cette feature de SIP n'en est pas une, vu que 1) c'est une feature des routeurs, et 2) y'a d'autres moyens pour le faire (certes ça marche peut-être pas en inter-domaines)

Ou DSCP.
C'est juste un champs utilisé par DiffServ ça. (mais on diverge)

H323 est une autre architecture et approche que SIP.
H323 a une approche telco, SIP a une approche "IP".
D'ailleur H323 n'est pas IETF.
Et ? SIP a une approche "HTTP" et XMPP une approche "XML" donc c'est différent donc c'est nul ? Avoir une approche différente ne rend pas un protocole meilleurs qu'un autre. Et que H323 ne soit pas IETF n'enlève pas le fait que c'est un standard.

>Tu m'as cité la bibliothèque pour me montrer que des gens trouvaient le protocole pas si compliqué,
Non, je t'ai cité une bibliothèque pour montrer qu'il peut etre simple d'utiliser SIP car il y a des bibliothèques dispo, donc on peut les utiliser directement.
Donc tu ne répondais pas à mon objection qui disait que le protocole est compliqué, je m'en tape qu'il existe une lib l'implémentant.

D'ailleur je vois pas ou tu as pu comprendre que je souhaitais que jabber implémente sip directement vu que j'ai parlé de factorisation.
Je vois pas où j'ai dit avoir compris ça...

(Sur une architecture SIP, c'est le boulot de RTP/RTCP ça ).
Pareil pour XMPP/Jingle

Ah ouais ok ... c'est du hors protocole...
La XSF est aussi une entité de standardisation, y'a pas que l'IETF dans la vie.

> une passerelle Jingle<->PSTN ferait pareil.
J'ai pas dis le contraire, j'ai dis que les passerelles SIP<->PSTN existaient déja, contrairement à l'implémentation d'une passerelle jingle<->PSTN. (tu crois vraiment que les telco vont s'amuser a rajouter des trucs a chaque nouveau protocole ?)
Ben si tu dis le contraire, tu dis que Jingle ne peux pas faire ça, et que SIP peut le faire. Ni Jingle ni SIP ne le font vu que c'est la passerelle qui le fait. On parle du protocole là, pas des implémentations.

J'en ai pas l'utilité donc personne ne doit en avoir l'utilité ...
J'ai dit ça où ?

Sans compter que faire de la QoS en devant faire de l'auto détection des flux (pour augmenter la prio sur le RTP), si il n'y a pas d'autres contraintes (ie aucune signalisation, signalisation offerte par SIP par ex) ca va etre chaud pour la faire ta QoS.
Y'a des méchanismes de QoS qui n'analysent pas les paquets de signalisations du protocole (IntServ et DiffServ par exemple si je ne dis pas de bétises).

Ah j'oubliais il faut que je rajoute jingle sur mes routeurs parce que ca t'ennuie d'utiliser les standards.
XMPP est un standard.

Mais si tu aime coder un truc qui existe déjà pour le plaisir que "toi tu sais mieux que les gars de l'ietf qui ont fait un truc spécialisé", je t'en prie fait le.
Viens juste pas pleurer ensuite que jabber ne se developpe pas.
Jabber est un standard de l'IETF.

J'ai dis qu'il y a déja eu un choix qui a été fait pour transmettre la voix et la signalisation.
Choix qui a été adopté par un grand nombre d'acteurs.
H323 aussi avait été adopté par un grand nombre d'acteurs, et pourtant SIP a quand même été developpé pour palier aux problèmes de H323.

Maintenant si tu es sur que jabber et jingle ont une masse critique pour pousser tous les acteurs a incoporer un standard qui fait exactement doublon avec SIP sur le point de vue VOIP/... (voir est meme moins bon que SIP), et qu'au final le consommateur en sorte vainceur.
L'intégration de la présence dans la voip est l'avenir (savoir que ton correspondant est en ligne avant de l'appeler est quand même bien pratique), et Jabber fait ça mieux que SIP (ne t'en déplaise). Après certes jabber n'a pas encore la masse critique et je n'ai jamais dit le contraire, mais SIP a ses débuts non plus n'avait pas la masse critique.

Si utiliser une librairie c'est plus compliqué que concevoir, recoder , incorporer , tester la fiabilité dui protocole, itou
la effectivement je crois que je peux plus rien pour toi.
Tu m'as cité la bibliothèque pour me montrer que des gens trouvaient le protocole pas si compliqué, puisqu'ils avaient réussi à en faire une lib, je vois pas le rapport avec l'utilisation de la bibliothèque. C'est les gens qui ont fait la bibliothèque qui ont du s'amuser avec le protocole, pas ceux qui utilisent.

Les RFC sont indispensable, mais il faut quand même pouvoir étendre de son coté le protocole avant de pouvoir le standardisé.

Pour citer un de tes anciens messages :
pourquoi SIP existe si ce n'est pas pour faire de la téléphonie de façon complète et sans "créer" des trucs hors protocole?
Donc en fait SIP ne voit pas toutes les possibilités et n'est pas complet (ça serait d'ailleurs impossible).

Donc en gros pour rajouter une fonctionnalité dans SIP il faut faire une extension et après rajouter une RFC là dessus, bref comme pour jingle. La différence c'est que SIP a plus d'extensions que Jingle, mais ça, ça va se corriger.

Et pour répondre à ta question,oui tu trouveras de quoi faire ces deux fonctionnalités dans les RFCs (plus d'infos sur: http://www.voip-info.org/wiki-SIP)
Tu parles desquels ? Damien en citait plus que deux, et je pense pas quelles soient toutes dans les deux RFC de base que tu me citais.

Et ces deux RFC définissent les fonctionnalités dont Damien parlait avant ?

Si faut refaire une RFC dès qu'on veut rajouter une fonctionnalité c'est pas très pratique.