IRC est l'un des plus vieux protocoles de l'Internet encore utilisé de nos jours par beaucoup de gens et notamment pas des équipes de développement de logiciels libre (sur les serveurs freenode principalement), mais également un protocole qui a des lacunes comparé à toutes les messageries instantanées. Pour pallier ces manques, des services ont été créés pour gérer les canaux, les pseudos, etc. Seulement, les implémentations ont eu tendance à diverger : pas exactement les mêmes commandes, pas les mêmes arguments, etc. Et surtout, aucun moyen pour les interfaces graphiques de fournir des réponses appropriées.
Et IRC+ arriva. Sous l'impulsion des développeurs de KVIRC, il s'agit d'une tentative pour harmoniser les commandes aux services. Lancée le 18 juin 2007 sous la forme de brouillon de RFC jusqu'au 20 décembre 2007, elle regroupe toutes les commandes usuelles ainsi que des réponses à donner aux clients IRC pour qu'il puisse fournir une interface graphique adéquate.
Le site : http://www.irc-plus.org/
PS: je n'ai aucun rapport avec cette initiative, je m'en fais simplement l'écho.
Journal IRC Plus, une initiative pour harmoniser les services IRC
7
août
2007
# ou alors...
Posté par Maxime (site web personnel) . Évalué à 8.
Dernierement j'ai dû étudier les solutions IRC / Jabber pour un projet qui va être mis en place. (Salons de discussion pour des étudiants)
Et dès qu'on recherche des trucs un peu "pointu" du genre :
- Véritable authentification des utilisateurs (avant leur connexion)
- Chiffrage des flux client-server
On s'aperçoit que IRC est vraiment à la traine. Alors que du coté de Jabber, ça évolue, on peut interfacer le système d'authentification avec le LDAP en 1 clic (OpenFire) ou quelques lignes de conf (ejabberd). On peut chiffrer les flux en TLS et tout.
Faut savoir s'arrêter et passer à autre chose.
IRC c'est cool, c'est beaucoup de nostalgie mais Jabber c'est l'avenir et son successeur.
[^] # Re: ou alors...
Posté par nicodache . Évalué à 10.
ca existe ca ?
nan parce que si c'est le cas, je configure directement mon pigdin pour attaquer ca plutot qu'utiliser mon vieil irssi.
le gros soucis, à mon avis, c'est le manque de gros serveurs jabber publics organisés en salon de discussion ; un truc pour remplacer irc quoi...
et les discussions à plusieurs, genre conférence àla msn/netmeeting n'ont rien à voir avec le plaisir que tu peux avoir à jouer sur irc, abus de pouvoir des op, des admins, les emmerdes dues aux splits, toussa, ca fait aussi partie du plaisir que j'ai à lancer mon irssi, et un serveur jabber me tente moins pour passer le temps pendant mes journées de glande au "boulot" qu'un vieux irc...
et pis, mon irssi, il tourne très bien dans son tunnel ssh avec authentification par clé, pas besoin de tls ;)
[^] # Re: ou alors...
Posté par Misc (site web personnel) . Évalué à 3.
Ensuite, faut reconnaitre, les clients jabber ne sont pas aussi aboutis que les clients jabber. Exemple, pas de script.
Pour ma part, je mise sur le support des salons muc dans bitlbee, mais c'est pas encore dans la version stable ( et j'aimerais bien qu'on merge mes patchs avant la fin des vacances :/ )
[^] # Re: ou alors...
Posté par Aldoo . Évalué à -2.
(PS : ce message est inutile)
[^] # Re: ou alors...
Posté par Gof (site web personnel) . Évalué à 6.
- Il existe des serveurs Jabber où l'on peut se connecter en tant que anonyme sans avoir de compte
- Par exemple certaines interface web ne demande pas de compte.
[^] # Re: ou alors...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . Évalué à 4.
[^] # Re: ou alors...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
<?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
<message from='expediteur@exemple.com' to='destinataire@exemple.net' xml:lang='fr'>
<body>Hello are you receiving this message ?</body>
</message>
</stream:stream>
Voici le même message envoyé avec IRC :
:expediteur@exemple.com PRIVMSG destinataire@exemple.net :Hello are you receiving this message ?
Quand on calcule le nombre de caractère (je ne compte pas les caractères blanc entre les balises pour xmpp), on a un paquet de 298 caractères pour XMPP contre 97 pour IRC. Soit un facteur 3.
Si on ne compte pas les parties variables (nom des destinataire/expediteur et le message en lui même), on a 214 caractères contre 13, soit un facteur 16 !
Bref, xmpp est beaucoup plus gourmand en bande passante que IRC et demande un peu plus de ressource au niveau du client puisque parser du XML est quand même beaucoup plus compliqué que de parser une commande IRC (m'enfin je chippotte, pour une machine moderne, la différence ne se voit pas, sauf peut être si on est connécté à 20 channels de 150 users en même temps avec des discussions trollesques à gogo).
Maintenant peut être que XMPP permet-il au client d'envoyer directement à tous les autres clients du channel, plutôt que de l'envoyer au serveur qui dispatch ensuite. Dans ce cas, il est probable que les serveurs ne souffrent pas autant que je le dis. Mais je n'ai pas regardé comment ça fonctionne exactement.
Note: c'est amusant^W delirant aussi de voir l'énorme différence entre un ping en XMPP et un ping IRC (envoyé entre client et serveur pour savoir par l'un si l'autre est alive et vice versa).
[^] # Re: ou alors...
Posté par Maxime (site web personnel) . Évalué à 4.
Déjà, pour envoyer un message, seul :
<message from='expediteur@exemple.com' to='destinataire@exemple.net' xml:lang='fr'>
<body>Hello are you receiving this message ?</body>
</message>
est envoyé.
Le reste a été fait une seule fois à la connexion.
Du coup on tombe à 135 caracteres donc un facteur de 1.5 comparé à IRC. Ton argument est divisé par 2.
"Maintenant peut être que XMPP permet-il au client d'envoyer directement à tous les autres clients du channel, plutôt que de l'envoyer au serveur qui dispatch ensuite. Dans ce cas, il est probable que les serveurs ne souffrent pas autant que je le dis. Mais je n'ai pas regardé comment ça fonctionne exactement."
Et bien il s'agit de la XEP 33 (http://www.xmpp.org/extensions/xep-0033.html ) si j'ai bien compris. Elle est en train d'être implémentée sur ejabberd dans le cadre d'un SOC.
Concernant le parsage du XML, je ne suis pas convaincu que ce soit vraiment plus compliqué que pour parser de l'IRC... Et puis niveau client ça doit effectivement ne pas se sentir.
[^] # Re: ou alors...
Posté par Gof (site web personnel) . Évalué à 6.
<message to='destinataire@exemple.net'>
<body>Hello are you receiving this message ?</body>
</message>
Le <stream/> ça sert à commencer la connexion le xml:lang et le from son tout a fait facultatif et sont omis dans les connections c2s
Ce qui ne fait plus que 103, ce qui est comparable au 97 de IRC
En plus, les connexions Jabber sont souvent compressées. Et le XML se compresse très fort vu que les éléments se répètent toujours
[^] # Re: ou alors...
Posté par briaeros007 . Évalué à 1.
Tu fait comment un xdcc sous jabber ?
[^] # Re: ou alors...
Posté par KiKouN . Évalué à 4.
Dès qu'il existe une méthode pour échanger publiquement ou en privé après un échange rapide en public une information, il existe une méthode pour échanger des fichiers "en tout genre". Le tout étant de la trouver est de la mettre en place.
Bon nombre de protocole ne visant pas à échanger des fichiers "en tout genre" ont étaient détourner pour le permettre: irc, news, etc... Cela étant d'autant plus facile lorsqu'il n'existe d'autorité centrale pouvant y mettre un frein.
Enfin, je pense que si une solution comme tu le désire existe ou doit exister sur jabber, elle serait plus élégante que xdcc.
[^] # Re: ou alors...
Posté par briaeros007 . Évalué à 2.
Je me doute qu'il y a bien mieux que le xdcc car c'est une bouse fini (n'ayons pas peur des mots). Mais comment faire migrer des personnes si il n'y a pas les fonctionnalités qu'ils attendent de façon simple?
En disant 'voui on a réfléchis et finalement on reste sur le principe de base et on regarde pas ce qui se passe actuellement' ?
[^] # bis repetita placent
Posté par Gniarf . Évalué à 2.
Jabber, l'avenir ? merci, mais non merci, vraiment.
[^] # Re: bis repetita placent
Posté par Xavier Maillard . Évalué à 6.
[^] # Re: ou alors...
Posté par Amand Tihon (site web personnel) . Évalué à 9.
Oh ben ça existe. IRC sur une connexion SSL, souvent sur le port 6697. Si je ne m'abuse, ça fonctionne au moins avec irssi (ça j'en suis sûr, je l'utilise), xchat et mirc. Je n'ai rien vérifié pour les autres.
- Véritable authentification des utilisateurs (avant leur connexion)
Tiens, ça existe dans le protocole IRC. La commande PASS, suivie d'un mot de passe, à envoyer au tout début de la connexion. Certains réseaux (dont celui où je suis impliqué) utilisent même ça pour automatiquement authentifier l'utilisateur auprès de NickServ.
Il va de soi que chaque type de serveur IRC peut choisir la manière dont il vérifiera le mot de passe : LDAP, mysql, fichiers de config ou autre. Que cette configuration se fasse « en un clic » comme tu dis, n'a rien à voir.
[^] # Re: ou alors...
Posté par Maxime (site web personnel) . Évalué à -5.
[^] # Re: ou alors...
Posté par Amand Tihon (site web personnel) . Évalué à 5.
C'est comme si je demandais si jabber est UserFriendly. Tu crois que celui qui utilise le plugin jabber d'irssi va répondre oui, sans hésitation ?
Le SMTP, c'est UserFriendly ?
Le problème posé ici, c'est qu'un réseau IRC actuel est constitué de deux entités qui sont couplées un peu trop lâchement : les serveurs, et les services.
C'est ça qui fait qu'il est un peu plus difficile d'avoir un client UserFriendly où il suffit de cliquer sur un bouton pour s'inscrire, ou pour réserver un canal de discussion.
Et c'est justement pour remédier à ça qu'irc-plus est proposé : apporter une descriptions des services proposés, pour que les clients puissent en tenir compte et offrir une interface plus UserFriendly.
[^] # Re: ou alors...
Posté par Maxime (site web personnel) . Évalué à 2.
"Le problème posé ici, c'est qu'un réseau IRC actuel est constitué de deux entités qui sont couplées un peu trop lâchement : les serveurs, et les services.
C'est ça qui fait qu'il est un peu plus difficile d'avoir un client UserFriendly où il suffit de cliquer sur un bouton pour s'inscrire, ou pour réserver un canal de discussion."
C'est exactement ce que je veux dire :
L'implémentation actuelle est telle qu'il est difficile de fournir un client UserFriendly.
Je ne fais qu'un bilan de l'existant. Peut-être qu'irc-plus va améliorer les choses, c'est en tout cas le but mais je vois que Jabber lui aussi bouge et il est quand même plus actif.
[^] # Re: ou alors...
Posté par Gniarf . Évalué à 2.
on peut faire user-friendly, c'est juste une question d'interface. et je te dis pas la gueule des users, en plus...
Jabber, depuis plus de 7 ans qu'il a démarré, je le vois surtout tourner en rond. comme système de présence, ça me convient, note bien
[^] # Re: ou alors...
Posté par Misc (site web personnel) . Évalué à 3.
Alors oui, en se basant sur irc, on peut faire un truc en dehors du standard, mais userfriendly.
[^] # Re: ou alors...
Posté par ribwund . Évalué à 2.
[^] # Re: ou alors...
Posté par Gniarf . Évalué à 2.
hormis ça, c'est toujours aussi épouvantable (couleurs, smileys et gif en tous genres comme //biere, usagers que j'aurais plutot tendance à fuir en général). ah, l'interface proposée (applet Java) empêche de sélectionner du texte (pour le copier), et tant qu'à faire, autant afficher de la pub partout, pour Meetic et autres
[^] # Re: ou alors...
Posté par Amand Tihon (site web personnel) . Évalué à 2.
C'est exactement ce que je veux dire :
L'implémentation actuelle est telle qu'il est difficile de fournir un client UserFriendly.
Si on met le mot "UserFriendly" aux normes actuelles, je crois que tout le monde est d'accord sur ce point, toi, moi, et ceux qui sont derrière irc-plus :)
[^] # Re: ou alors...
Posté par Beretta_Vexee . Évalué à 5.
Question de point de vue, si la première norme à mit peut de temps a sortir sa stagne énormaimant les dernières innovations sont dut a Google (VOIP/Video, jiggle, etc.) et pas au consortium.
A partir Jabber c'est bien c'est moderne et ça utilise XML ( argument dont beaucoup sont revenue ) ça ne casse pas trois patte à un canard. C'est inutilisable pour le moment pour les conférence, ça ne remplace pas l'IRC dés qu'on à vraiment beaucoup de monde et ça manque cruellement de serveur ( hors google).
IRC est vieux mais éprouvé, a une plétor de serveur, de réseau, de client, ne demande presque rien comme ressource ( CPU et bande passante ), se script bien et fait ce qu'on lui demande ( des channel à 50-100 couillion qui discute, s'insulte et joue à superquizz ). Donc non il ne faut pas tuer l'irc trop vite, si il y a encore du monde dessus c'est peut être parce qu'ils n'ont pas trouvés mieux ailleurs.
Cordialement
[^] # Re: ou alors...
Posté par briaeros007 . Évalué à 3.
C'est pour ca que les admins g-line si tu as 3 clones, que pour les xdcc tu vas chercher les listes sur http ou sur ke premier fichier, parce que sinon ca met beauocup trop de temps (limitation du nombre d'octets/s d'un utilisateur).
Tout n'est pas parfait sur irc non plus.
[^] # Re: ou alors...
Posté par Amand Tihon (site web personnel) . Évalué à 1.
S'il y a un nombre, variable suivant les réseaux, de clones autorisés, c'est simplement pour limiter les abus. Si tu prévois une petite sauterie bug squashing party chez toi pour un #projet donné, avec 15 personnes sur ton adsl, je suis certain que les administrateurs, dûment prévenus, feront une exception.
limitation du nombre d'octets/s d'un utilisateur
Ça doit être pour ça qu'il existe le DCC (Direct Client-to-Client) chat, qui ne passe pas par les serveurs.
[^] # Re: ou alors...
Posté par briaeros007 . Évalué à 1.
c'est simplement pour limiter les abus.
Et quel abus ? Si ca consommait tellement peu, les "abus" ne devrait avoir aucun effet.
Ça doit être pour ça qu'il existe le DCC (Direct Client-to-Client) chat, qui ne passe pas par les serveurs.
Et ?
Je connais tres bien le dcc vu que je l'utilise tous les jours. La limite montre juste que selon toute vraisemblance, qu'un serveur irc a un impact non négligeable en bp.
[^] # Re: ou alors...
Posté par briaeros007 . Évalué à 1.
Sous xchat c'est pas plus compliqué que sous psi (pour jabber).
Par contre, dans irc il y a pas le chiffrement client à client.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . Évalué à 6.
J'ai pas souvenir avoir vu freenode en ssl, ni undernet, ou quakenet ( 3 gros serveurs que j'ai pris au pif ), par contre, je pense que tout les serveurs jabber le proposent de base.
Quand à l'usage de la commande PASS, pourquoi est ce que personne l'utilise ?
Et il reste aussi le probléme du fait que si je veut aller sur 3 salons sur 3 serveurs différents, ben j'ai 3 comptes différents. Et aussi 3 nicks names, je pense qu'on peut faire mieux en matiére d'auth.
[^] # Re: ou alors...
Posté par Beretta_Vexee . Évalué à 3.
3 réseaux publiques
Quand à l'usage de la commande PASS, pourquoi est ce que personne l'utilise ?
Parce que tu prend comme exemple des réseaux publiques qui part définition sont ouvert à tous. Personnellement je bosse sur un site avec SSO et dont le système de chat est basé sur un serveur IRC parce que c'est infiniment plus simple que jabber a mettre en place.
Et il reste aussi le probléme du fait que si je veut aller sur 3 salons sur 3 serveurs différents, ben j'ai 3 comptes différents. Et aussi 3 nicks names, je pense qu'on peut faire mieux en matiére d'auth.
Et en quoi Jabber répond à ce problème ? Si je veux me connecter à deux serveurs non interconnectés ( privés ) différents, je dois aussi avoir deux comptes différents.
[^] # Re: ou alors...
Posté par rewind (Mastodon) . Évalué à 10.
IRC est loin d'être un protocole trop vieux. Il est encore très utilisé pour une raison : il comble un besoin que ne comble pas d'autres protocoles comme Jabber ou MSN. Surtout si des gens tente de faire évoluer IRC comme avec cette initiative.
Alors crier qu'il faut utiliser Jabber, moi je veux bien, mais je suis loin de trouver le confort et le plaisir d'IRC dans un salon Jabber. Je ne veux pas cracher sur Jabber parce que je l'utilise quotidiennement, mais il faut arrêter de dire que Jabber va remplacer tout : mail, IRC, toussa. Si Jabber pouvait déjà faire de la messagerie instantanée comme MSN, je serai déjà très heureux.
[^] # Re: ou alors...
Posté par NickNolte . Évalué à 6.
Oh mon dieu!
C'est a dire? Wizzz? Substitution de mot par des images? connexion non-chiffre? et que sais-je???
Et pour le reste, je n'ai jamais pu faire de la visio et de l'audio convenablement sur MSN 6,7,8...
[^] # Re: ou alors...
Posté par Beretta_Vexee . Évalué à 2.
[^] # Re: ou alors...
Posté par briaeros007 . Évalué à 3.
Et le monsieur a dit juste avant :
Et pour le reste, je n'ai jamais pu faire de la visio et de l'audio convenablement sur MSN 6,7,8...
petit conflit :D
Quand aux vitesses de transfert j'ai jamais eu de probleme ni avec jabber ni avec irc.
[^] # Re: ou alors...
Posté par zul (site web personnel) . Évalué à 2.
Apres tout dépend du contexte. Les réseaux internes sont surement très bien avec du XMPP. Pas de problème de scalabilité réseau, et plein de services associés. Apres, pour monter un réseau de la taille de freenode over XMPP, j'ai des doutes.
Psyc a l'air d'être une alternative intéressante. Evidemment, il n'y a pas de vrai client, la seule implémentation est écrite dans un langage peu connu, je doute que ca perce fort. Mais ils ont des approches intéressantes pour les problèmes de Routage des messages.
[^] # Re: ou alors...
Posté par Aldoo . Évalué à 1.
[^] # Re: ou alors...
Posté par moo4 . Évalué à 2.
J'aimerais comprendre l'interet. Avoir une connexion sécurisé sur un chan de 300 personnes inconnues qui peuvent loguer la conversation ?
[^] # Re: ou alors...
Posté par briaeros007 . Évalué à 1.
Par exemple tu envoie ton mdp ... en clair par défaut (sauf si tu te co au serveur en ssl).
[^] # Re: ou alors...
Posté par moo4 . Évalué à 2.
[^] # Re: ou alors...
Posté par Aldoo . Évalué à 2.
Maintenant, si effectivement le seul intérêt de SILC sur IRC est la sécurité, ce dont je doute, alors SILC ne répond pas à la problématique initiale.
[^] # Re: ou alors...
Posté par srm . Évalué à 0.
C'est vraiment un IRC+ je trouve.
Merci pour la remarque tout en bas de page, j'avais pas vu le post sur SILC pourtant j'avais fait un CTRL+F Silc, j'ai du passer à coté.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . Évalué à 4.
1) manque de reliabilité. contrairement à l'expérience de l'auteur, j'ai jamais vu de message perdu. J'ai souvent vu mon serveur tenté de renvoyer les messages, sous la forme de message d'erreur multiple.
2) idle connection. Probléme d'implementation, mais il n'y a pas de lien vers les rapports de bugs si ils existent.
3) roster Asynchronicity, pas de méthodes exacts sur comment reproduire le probléme. Et une fois encore, c'est un probléme d'implémentation.
4) Scalability. Il y a une xep (xep 0133 ) sur le multicast pour ça (et l'intégration en cours dans ejabberd ). Et je suis désolé, c'est pas des pourcentages qu'il faut donner pour savoir si ça monte en charge, mais la bande passante utilisé. Au boulot, on a coupé le cache dns de windows, on a eu une augmentation de 200% du trafic dns interne, clairement vu sur les graphes par un passage de 1k de bande passante à 3k. 200%, ça fait beaucoup, 2k de trafic réseau, ça fait rien en réseau local. Avant de dire que jabber ne scale pas, il faut déja savoir si le probléme vient de la bande passante, de la mémoire, ou d'autres choses.
5) Probléme pour savoir si un noeud est up ou pas. Il y a la xep-0199, pour le ping, qui est relativement trivial à implementer.
6) XML, soit l 'auteur n'aime pas xml. Parce qu'il peut pas transferer des données binaires, parce qu'on peut pas décider de réduire les données à un seul octet ( et tant pis pour l'extensibilité ), parce qu'on peut pas étendre xml facilement, bref, des tas de raisons aussi valides que les commentaires à la fin de la page
7) Xmpp vs Xml, il a pas du lire la rfc qui dit que le protocol sert à streamer des éléments en xml, pas que le flux soit forcement un document valide. Néanmoins, l'auteur ayant la bonne idée de coller des morceaux en allemand, j'ai du sans doute mal comprendre.
8) Having to Guess the Meaning of a Packet, oui, ça s'appelle un protocole extensible. Psyc, permettant la même chose ( à savoir spécialiser les messages ), aura sans doute le même probléme, si un jour il est étendu.
9) MUC the "Multi-User Conference", on passeras sur l'attaque à la con, tout les wikis ne sont pas la pour qu'on pose des questions en toute anarchie, et concentrons nous sur le fait que oui, la forme actuelle des mucs ne permet pas d'avoir 700 personnes dans une chatroom. Soit, et vu l'état actuel, en quoi ça pose probléme, car j'ai jamais vu un salon avec plus de 25 personnes ? Des gens sont conscients du probléme, travaillent dessus ( http://www.xmpp.org/extensions/inbox/distributedmuc.html ), et je pense que ça sera réglé en temps et en heure. Il est connu qu'avec des ressources limités, on peut pas tout faire en même temps.
Le reste est du même tonneau. Bien qu'ayant certaines critiques valides, je pense que la plupart sont noyés sous un style provocant, et sous des manques des initiatives récentes.
Pour en revenir à freenode, irc et les mucs, il faut bien voir que la structure du réseau jabber en forme de federation est bien plus scalable à mon sens que les approches en réseau séparé d'irc, mais peut être que mon intuition est fausse.
[^] # Re: ou alors...
Posté par Gof (site web personnel) . Évalué à 3.
C'est normal que tu n'ai jamais vu de message perdu puisqu'ils sont perdu :-)
Mais moi qui ait parfois des problème de connexion, j'en vois beaucoup des messages perdu quand je demande à mes contact de répéter ce qu'ils disaient.
Mais des solutions sont en cours de propositions (XEP-0198)
Et pour le reste je suis d'accord avec toi
[^] # Re: ou alors...
Posté par Maxime (site web personnel) . Évalué à 3.
*Toto has quit : Ping timeout
Et puis tu l'as dit, il y a des solutions envisagés. Donc ce problème ne sera plus dans quelques temps.
[^] # Re: ou alors...
Posté par zul (site web personnel) . Évalué à 2.
Les auteurs de ces pages me semblent relativement compétents, à savoir qu'ils ont réfléchis aux problèmes de IRC et co et qu'ils ont proposés une solution. Ils ont aussi implémentés assez d'IRC et de XMPP pour que l'accès à Psyc soit "transparent". Il est probable aussi que leur(s) avis soient biaisés et qu'ils défendent leur solution.
Le seul reproche que je fais à XMPP au final, c'est d'essayer de créer un protocole permettant de résoudre n'importe quel problème :). Encore un produit miracle qui lave plus blanc que blanc. Enfin ca veut dire quoi derrière ? Ca veut dire que les serveurs sont compliqués à implémenter, que les clients sont aussi extrèment compliqués à implémenter, et qu'en plus, il faut avoir un design assez souple pour pouvoir assurer qu'on va pouvoir intégrer les 200 prochaines XEP qu'on va nous pondre. A des années lumières du mouvement KISS.
IRC a l'avantage d'être un protocole simple, et on a vu deja les "dizaines" de bug d'implémentation des différents serveurs. Je ne vois pas comment cela pourrait être mieux avec XMPP, qui devient chaque jour plus difficile à implémenter.
Enfin, 25 users sur un chan c'est ridicule (pour IRC).
NB : J'utilise XMPP en tant qu'IM je ne suis pas un anti-jabber. J'aimerai juste que cela reste un protocole simple et non un truc qui essaye de résoudre tous les problèmes du monde.
[^] # Re: ou alors...
Posté par Beretta_Vexee . Évalué à 1.
Tien moi aussi étudiants/jeune diplômé/ancien élèves.
Et dès qu'on recherche des trucs un peu "pointu" du genre :
- Véritable authentification des utilisateurs (avant leur connexion)
Ca existe/sa se fait, nous on a du SSO sur tous le site et même un système gère les invitations pour bloquer certains salons.
- Chiffrage des flux client-server
Quel intérêt dans ce cas précis va y avoir beaucoup de conversation digne d'être écouté par la NSA sur votre serveur ? Tu vas charger ton serveur pour une fonctions que les utilisateurs ne verront pas ou dont il ne comprendront pas l'utilité, pour te prémunir d'une menace très faible. La plus part des mails sont acheminés sans être cryptés pourtant ils sont potentiellement beaucoup plus sensible.
Dagne des ressources CPU et fait tourner un anti-spam/anti-virus sur ton serveur de mailling list, ce sera plus utile.
[^] # Re: ou alors...
Posté par Maxime (site web personnel) . Évalué à 2.
S'agissant du réseau Renater, ils tiennent à ce que seul les étudiants de l'école puissent se connecter sur le serveur.
Ils ne veulent pas que les mots de passes puisse circuler en clair non plus d'où le chiffrage de la connexion client-server.
Avec IRC on se retrouve vite dans des solutions dignes de l'appellation de "hack".
Ces conditions n'étant pas les seules, il s'avère que Jabber s'est montré comme étant la meilleure solution bien que nous soyons initialement parti pour un serveur IRC.
Je m'occupe du club informatique de mon école, je n'ai pas la possibilité de décider de la répartition des ressources CPU entre chaque serveurs :).
[^] # Re: ou alors...
Posté par Beretta_Vexee . Évalué à 0.
Ou ça commence mal.
S'agissant du réseau Renater, ils tiennent à ce que seul les étudiants de l'école puissent se connecter sur le serveur.
Ils ne veulent pas que les mots de passes puisse circuler en clair non plus d'où le chiffrage de la connexion client-server.
Ou lala, tu sais que dans une tel configuration tu n'es absolument plus maitre de ton affaire et que virtuellement l'académie et l'administration de ton école peuvent vous couper quand bon lui semble à sa discrétion.
L'école c'est très bien pour les sauvegarde et les serveur de devs, mais faut pas tous faire tourner chez eux sans quoi on s'expose à des problèmes sur le long terme.
Avec IRC on se retrouve vite dans des solutions dignes de l'appellation de "hack".
Si tu as solution peut gourmande et efficace pour gérer ça en jabber je suis preneur . Si en plus ça peut se faire via le navigateur web c'est la fête.
Ces conditions n'étant pas les seules, il s'avère que Jabber s'est montré comme étant la meilleure solution bien que nous soyons initialement parti pour un serveur IRC.
Les serveur en mesure de tenir notre charge n'était pas assez flexible ( le SSO demandait vraiment trop de boulot ), on a aussi testé googleapps ( jéte un oeil c'est gratuit pour les établissement d'enseignement ) qui permet de faire du SSO facilement mais ne permet pas encore de gérer les salons de discutions etc etc . Ce qui ne répond pas a nos besoins.
# Il faut accepter....
Posté par NickNolte . Évalué à -5.
Si IRC+ devait aboutir, tant mieux mais honnetement, c'est deja trop tard.
Il y a clairement plus rien a retenir d'IRC, on lui rend hommage et on tourne la page, c'est aussi simple que cela.
Si Freenode pouvait emboiter le pas assez rapidement, ca serait clairement un bond en avant.
# Et Silc alors ?
Posté par srm . Évalué à -1.
N'est ce pas LE remplacant de l'IRC ?
L'IRC n'est pas mort, les serveurs IRC se sont pas plus petit qu'avant, voire plus grand.
[^] # Re: Et Silc alors ?
Posté par srm . Évalué à -6.
Je vous en serais reconnaissant
[^] # Re: Et Silc alors ?
Posté par Maxime (site web personnel) . Évalué à 1.
Bon et j'imagine qu'il y a d'autres raisons aussi... Réfères toi à l'autre message justement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.