Jehan a écrit 1652 commentaires

Hein? Mais de quoi parlez-vous? Excusé de quoi? Croire en quoi?

C'est une honte maintenant d'avoir des joujoux et on doit en être excusé? Quel est le rapport avec ce que je raconte? Bon j'arrête de répondre à ces messages ridicules. Je regarde les messages des gens qui sont intéressés par ce que je raconte et qui répondent des choses intéressantes sans chercher à attaquer une bête requête d'information.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

je suis tout à fait d'accord. Racheter une webcam serait le plus simple SI ça M'intéressait de faire des meetings vidéo à tout bout de champs. Mais si ça avait été le cas, j'aurais simplement acheté la webcam moi-même depuis longtemps. Donc bah ça me paraît évident ici que le point n'est pas pour moi de m'acheter du matos pour faire des video confs (ça c'est pour l'entreprise), mais qu'on me propose de m'acheter un truc aussi cher et ridicule qu'un ipad2 juste pour de la video conf, et donc que je me dis que je peux profiter de l'occasion pour acheter un autre matériel complémentaire à ce que j'ai, éventuellement pour faire joujou avec Android ou Meego peut-être (et avec du matos type "portable" de manière général, car je n'ai pas de téléphone), ou pour avoir un matos encore plus petit que ce que j'ai pour me déplacer (vous aurez compris que je suis un adepte des matériels adaptés pour se déplacer), ou autre (proposez des idées!). Je crois qu'il n'est pas interdit encore de se faire payer des joujoux (qu'on n'aurait probablement pas achetés sinon)?

D'ailleurs je n'ai jamais dit que je comptais remplacer mon netbook (en fait, je crois même avoir dit l'inverse), ce que je crois lire comme reproche dans votre message. Je continuerai à l'utiliser et comme j'ai dit, j'en suis très content. Mais on me propose un truc comme ça. Je dis juste "pourquoi pas? Mais pas du Apple". Et donc je viens demander des conseils aux linuxfriens (en oubliant apparemment ceux qui viennent constamment faire des procès d'intentions) sur ce que vous connaissez et si vous connaissez des gadgets dans cette zone de prix qui pourrait m'être utile et m'amuser pour développer dessus (du Logiciel Libre en plus!), tout en restant dans le critère simple de la boîte.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

je n'ai malheureusement pas joué à Super Tux Kart car je n'ai qu'un netbook, mais ayant de bons souvenirs de Super Mario Kart avec des amis, ça me dirait bien un jour d'essayer, surtout voyant divers commentaires enthousiastes ici.
Juste pour rebondir sur les joueurs trop disséminés. C'est en effet un des bon trucs de SMK: le jeu "triche" clairement pour s'adapter aux joueurs. Mais ce, dans les deux sens: si on est super bon, mais qu'on fait une erreur, y a toujours un ou deux kart pour nous dépasser/rattraper, donc on reste constamment concentré; d'un autre côté, un débutant mauvais a toujours possibilité de rattraper les derniers, voire d'arriver à une bonne place si on se réveille au dernier tour.
Aussi oui clairement les bonus sont pas si aléatoires mais pensés pour donner une chance au dernier qui reçoit tjrs les meilleurs bonus: la carapace bleue, l'éclair, l'étoile, etc. alors que le premier se récupère des vertes ou des rouges (bcp moins utile quand on est premier). On connaît tous le plaisir de faire une course de merde et de passer premier dans les derniers mètres de façon inattendue, ou la rogne de se faire passer par une IA ou un pote de la même façon alors qu'on croyait la victoire assurée (et si le jeu était "juste", elle devrait l'être).

Je pense que ce jeu applique clairement un principe que je nommerais "IA pour le fun", totalement injuste mais le but étant clairement de donner une chance à tous pour s'amuser avec des joueurs à niveaux inégaux (enfin pas trop non plus) et donner du piment. Donc c'est bon pour le jeu en groupe, mais aussi pour s'amuser seul.
Si ce n'est déjà fait donc, ce genre de principe doit pvr s'appliquer à STK.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

"Objectivement"? Ben que veux-tu que j'en sache! C'est bien ce que je dis, à part avoir accès à des univers parallèle ou bien à acheter une dizaine de batteries et faire des tests pendant quelques années avant d'acheter le portable qui utilise cette batterie. Donc je fais confiance aux notices des machines, aux constructeurs, et aux divers "spécialistes" (auto proclamés ou non, car honnêtement je sais pas faire la différence puisque j'y connais rien).
C'est donc un peu idiot comme question. On est bien à un moment donné obligé de faire confiance aux conseils qu'on reçoit. On peut pas tout savoir/tester soit-même.

Quant aux tests et au protocole de test, j'ose pense que les constructeurs de batterie les font avant de nous donner ce genre de conseil.

Et non, je suis désolé, mais changer de 6 mois la durée de vie d'une batterie, c'est pas rien. C'est énorme dans une logique où on essaie de ne pas gâcher les choses sous prétexte que "y a qu'à racheter, ça coûte rien". Si tout le monde faisait comme ceux qui font gaffe à leurs batterie pour l'ensemble des trucs qu'ils achètent, y aurait sacrément moins de gâchis et de pollution.

Et même pour une seule personne, si on considère que la batterie sera à changer au bout de je-ne-sais-combien d'années (par exemple le Toshiba que j'avais, je crois que je l'ai gardé environ 6 ans et n'ai jamais eu à changer la batterie d'origine. J'ai donné le portable à la fin à quelqu'un uniquement parce que j'avais changé de besoin pour quelque chose de plus petit), je pense que 6 mois, ça peut tout changer. Par exemple si au bout de 7 ou 8 ans, je dois changer pour une nouvelle batterie (alors que je doute que le portable durera 15 ans en tous, d'autres parties claqueront avant), ça peut faire qu'on a acheté une nouvelle batterie (vieille technologie et probablement inutilisable sur les machines récentes) pour rien. Donc v'là le manque d'écologie.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

mes sources sont d'une part les diverses sources sur internet expliquant cela. Le lien juste au dessus de pankkake par exemple donne encore les même genres de conseils (en suivant un autre lien dedans qui parle de maintenance): http://www.thinkwiki.org/wiki/Maintenance#Battery_treatment

Une autre source est la notice des machines. Si tu regardes, y a toujours une liste de recommandations pour les batteries qui dit un peu le mēme genre de règle (pas forcément toujours exactement les mêmes, ou bien pas aussi complet, mais globalement la même chose), mais que personne ne lit. Ben moi je les lis.

Ma batterie tient encore plutôt bien (environ 18 mois depuis achat, je pense), mais je ne peux comparer avec si j'avais pas fait gaffe (parce que pour ça, je devrais trouver un univers parallèle avec un moi qui aurait laissé constamment la batterie dessus et qu'on fasse un test de comparaison). Donc je fais une confiance aveugle aux recommandations diverses quant à la maintenance.

Ensuite si tu es comme la plupart des gens et que la mobilité d'un portable est entre chez toi et ton travail, ou entre ton divan et ton bureau, etc. avec une fois de temps en temps un besoin sans prise secteur, dans un café ou autre pour 2/3 heures au plus, oui je comprends tout à fait ta démarche. Par contre dans mon cas, l'autonomie et la mobilité sont très utiles et furent même l'un des critères majeurs de choix de mon ordi (c'est pour ça que mon seul ordi est un eeepc, soit un notebook que je fais durer entre 6h et 7h, avant plus, en utilisation normale, parfois assez chargée).

Enfin dernier point, même si le problème n'est pas financier, je n'aime pas l'argumentaire "on peut en racheter une pour pas cher". Déjà j'aime pas l'idée qu'on doive toujours acheter des choses. J'aime bien faire durer ce que j'achète (disons que si je pête mon ordi sans faire exprès, je m'en fous. C'est pas grave, c'est que du matos; mais pendant que je l'ai, j'en prends soin quand même). Et puis toute cette électronique, notamment les technologies batterie, sont très mauvaises écologiquement. Donc si je peux éviter…
Enfin en plus du fait que je suis pas très matérialiste et donc que j'aime pas plus que ça acheter plein de trucs, je peux pas me le permettre non plus car je bouge beaucoup. Donc l'ensemble de mes possessions doivent être contenables dans deux petits sacs que je trimballe (et en gros ce petit eeepc est déjà l'une de mes possessions les plus lourdes et prenant de la place, donc acheter en plus une seconde batterie, j'évite).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

je vois. De ce que je retiens de tous les commentaires réponse, c'est que les batteries de petit matériel électronique et de véhicules n'ont donc rien à voir. Le meilleur espoir pour améliorer l'expérience utilisateur de tels machines, c'est donc qu'une API qui permette de stopper/reprendre automatiquement la charge se généralise (laissant des options pour prendre la main, mais par défaut "décidant" à la place de l'utilisateur pour optimiser la vie de la batterie), comme indiquée plus bas (mais le lien indique une API pour Thinkpad seulement apparemment :-/).

Ceci est d'ailleurs valable pour les systèmes utilisant les piles, ces règles ne sont que des règles de bon sens qui fonctionnent quelque soit la technologie.

Hmmm... Je ne crois pas vraiment qu'on puisse dire que ce soit du "bon sens". ;-)
Ce sont des règles qu'on sait parce qu'on nous les dit et qu'on les apprends, mais je ne considère pas que savoir qu'il ne faut pas charger complètement une batterie, mais pas non plus la décharger complètement, etc. soit une évidence. C'est bien pour cela que c'est un sujet si compliqué d'ailleurs.
Et puis on voit bien qu'il y a autant de règles différentes qu'il existe de technologie de batterie, alors pour ce qui est du "bon sens"…

Sinon pour le commentaire plus haut qui conseille de garder la batterie comme onduleur. Bon j'y connais rien en onduleur et apparemment on lui répond que ça marche pas pour en remplacer un. Mais de manière général, simplement avoir une batterie et pouvoir se débrancher d'un endroit est déjà super pratique. En gros le portable a permis aux utilisateurs de devenir semi-mobiles. La plupart va utiliser son ordi presque uniquement chez soi, mais ça lui permet de se déplacer de son bureau, au salon, puis son lit sans jamais avoir à arrêter l'ordi. Juste en se débranchant/rebranchant. Et c'est ce qui m'embête le plus dans le fait de ne pas mettre ma batterie pour la préserver (car je me balade aussi beaucoup en dehors de chez moi et ai donc besoin d'autonomie).
Avant ça ne m'embêtait pas car je pouvais la mettre/l'enlever sans blem en étant branché (j'avais un vieux portable Toshiba à l'époque). Maintenant j'ai juste un eeepc. J'ai essayé quelques fois de retirer/mettre la batterie, mais en fait ben des fois, j'enlève la batterie, ça s´éteint; ou bien je la remets, puis débranche, ça éteint aussi (aurais-je dû attendre plus longtemps? J'avoue n'avoir pas voulu jouer trop avec ce genre de chose); et de manière général, les quelques fois où ça marchait (pquoi?) les icônes indiquant l'absence/présence/charge de batterie ne se mettaient pas à jour, donc je n'avais aucune idée de ma charge actuelle.
En gros avec mon eeepc, quand je me branche sans batterie, je deviens fixe. Et je suis obligé d'éteindre l'ordi pour me déplacer. Très chiant.

J'ai vraiment besoin d'une API de charge intelligente pour pouvoir laisser constamment la batterie sans jamais avoir à me soucier de diminuer la durée de vie de la batterie.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

bon apparemment cette API permet de stopper/démarrer une charge, mais pas d'en changer la puissance comme fait le chargeur intelligent pour batterie de véhicule. Mais en même temps, d'après ce que certains disent plus haut, ce genre de technique ne s'applique de toutes façons pas aux batteries d'ordi dont la procédure de maintenant se limite à arrêter/reprendre.

Par contre je vois aussi que ce pilote est dédié aux Thinkpad, au moins à l'origine. Cela s'est-il répandu depuis? Existe-t-il une telle fonctionnalité qui soit plus générique pour plus de matériel? Car ce genre de fonctionnalité serait tout de même intéressant pour tous ceux qui ont un portable et qui, comme moi, passent leur temps à en retirer la batterie, à la remettre, à la vider de temps en temps exprès, même quand on est proche d'une prise courant. Etc.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Bon et sinon vous êtes dans quel coin, si cela n'est pas trop indiscret?

Dernièrement principalement en Corée. Je passe régulièrement au Japon aussi. Sinon je crois qu'on peut se tutoyer sur ce site, sauf si vous insistez vraiment pour qu'on se vouvoie.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

quand tu parles de taille monstrueuse des paquets, peut-être aussi est-ce "par rapport" à sa qualité moyenne. Donc forcément des codecs plus récents comme Speex sont bien plus optimisés avec donc une bien meilleure compression, mais en absolu (faisant abstraction de la qualité), l'échange en g711 sera moins gros que l'échange Speex, non?

Pour ce qui est de ne pas être en vogue en téléphonie, je pense que tu entends que ce n'est pas populaire car on aimerait tous s'en débarrasser, mais dans les faits, on est pris au piège par l'infrastructure (historique) existante. Moi c'est ce que j'ai compris. En tous cas, tous ceux qui bossaient ou avaient bossé en téléphonie tenaient le discours que c'était la base codec minimum présente dans toute technologie télécom.
Il faut donc bien comprendre qu'il s'agit, pour nous aussi, d'un choix uniquement pragmatique. C'est "le codec que tout le monde doit au moins avoir parce qu'il marchera partout et y a aucune raison de pas l'implémenter tellement il est simple à implémenter" (on trouve des implémentations en quelques dizaines de ligne). Mais ce n'est nullement un codec conseillé. Idéalement il ne sera jamais utilisé mais il sera toujours là en roue de secours.

Ensuite oui Speex était clairement notre second espoir pour cette place de codec par défaut, et il aurait sûrement pris la place si s'intégrer aisément au monde de la téléphonie n'avait eu aucun intérêt. Ce point a été décisif.
Note que si les réseaux télécoms évoluent et que le codec G.711 disparaît, nos propres spécs évolueront. En tous cas, il me paraît évident que dans le monde de la VoIP, ce ne sera presque jamais le codec utilisé entre deux clients VoIP. Speex a beaucoup d'implémentations et il y a aussi peu de raison de ne pas l'implémenter.

Mais il y a de fortes chances que Speex n'évoluera plus beaucoup maintenant que son auteur lui-même essaie de l'enterrer au profit de son nouveau joujou.
Un dernier truc dont je n'ai pas parlé dans le billet, c'est que Speex est orienté voix et est apparemment vraiment mauvais dans plein d'autres domaines audio (c'est vrai aussi de G.711, mais c'est pas ça qui fait qu'on l'a choisi, comme je disais plus haut). C'était une bonne idée quand on pensait uniquement "Voice over IP" mais maintenant on pense plus large. En gros, je ne suis pas sûr que Speex a beaucoup d'avenir maintenant.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

XMPP est toujours très en retard sur ses "concurrents" (en fait, je pense surtout à Skype, qui s'est fait un nid royal en entreprise, et désolé de le dire, mais que je recommande à mes parents parce que "ça juste marche!").

Oui. Mais vois l'état des "concurrents" de nos jours. Les gros d'avant — MSN, ICQ, AIM, Skype… — ne sont plus que des dinosaures en voie d'extinction qui font de la lêche aux primates d'aujourd'hui (Google et Facebook qu'ils se mettent à intégrer dans leurs clients respectifs). Ces deux nouveaux grands de l'IM se trouvent tous deux utiliser… XMPP (bon un seul est fédéré)! Parmi eux, AIM/ICQ commence à se mettre sérieusement à XMPP (officiellement); Skype est effectivement celui qui a encore la meilleure "aura" en VoIP, mais cela n'empêche pas qu'il n'est plus rentable, qu'il a donc été vendu (une fortune certes, mais certains disent que ce prix était de la folie, l'avenir nous le dira), et que leur récent "business model" semble être de se décider à faire le larbin de celui qui marche (Facebook que leur client "supporte" maintenant); MSN, bon bah ils sont juste devenus quasi inexistants.
Alors peut-on vraiment parler de réussite? Certes sur un plan financier, certains ont dû profiter largement pendant que ça durait et s'en sortiront très bien, mais l'avenir est compromis pour ces technologies. C'est du court terme.

Ca va changer, mais pas tout de suite, et pas forcément vite. Euh, je pense pouvoir ressortir ça sur XMPP dans des articles et forums depuis des années "c'est presque prêt", "ça arrive", etc. Donc on est pas prêt de voir le retard rattrappé, et d'ici là, Skype sera sans doute amélioré (ou simplement livré en standard avec tous les Windows, intégré à MSN/autre, ça suffira...). Y'a-t-il une prise de conscience du mal qui peut être fait par le temps sur le succès de XMPP?

Je crois que c'est se voiler la face que de ne pas voir la prédominance de XMPP de nos jours. Le standard fait son bonhomme de chemin, tranquille certes, les gens ne connaissent pas le nom du protocole derrière (et perso, on s'en fout. Va parler de POP3, IMAP ou SMTP aux gens), mais si on fait des chiffres d'utilisation (cad pas en comptabilisant les "comptes morts"), je suis persuadé que nous sommes numéro 1 (peut-être numéro 2 si on ne compte pas Facebook car ils valent pas mieux que les autres et sans être fédéré, ils comptent pas vraiment).
Pendant ce temps, les autres viennent ou viendront petit à petit (AOL par exemple très bientôt, espérons le).

XMPP en tant qu'organisme semble avancer au gré des coups de pied au cul de Google. Bon, c'est méchant de le dire comme ça, mais c'est MON impression: beaucoup de débats, de pour et de contre, et d'un coup Google arrive et "moi je fais comme ça, vous suivez et on le standardise, ou sinon je peux le faire tout seul avec mes millions d'utilisateurs...". D'un côté, c'est bien qu'une boite comme Google fasse avancer les choses dans le bon sens, d'un autre, est-ce que l'XMPP n'est pas en train de devenir un service d'optimisation et validation pour le "protocole Google"?

Oui cela s'est passé beaucoup ainsi pour certaines technologies (la VoIP en particulier). Pour le reste, ils ont fait comme tout le monde et ont profité de ce que les autres ont développé. La base du protocole, les MUCs, les vcards, la plupart des fonctionnalités XMPP, ils ont simplement suivi ce qui existait et marchait. Même dans les trucs récents: l'identification SCRAM par exemple, je trouve ça purement génial comparé à ce qui se fait de nos jours, par exemple dans le web; le versionnement de roster; tous les trucs qui se sont fait à partir de Jingle sans rapport avec Google (les Nodes, etc.).
Pour la vidéo, forcément quand ils sont arrivés, il n'y avait rien qui avait fait son nid, donc ils ont comblé un manque. On ne va pas rejeter cette fonctionnalité dont les contributions ont suivi les règles (pourquoi le ferait-on? Pour faire les rebelles? Parce qu'on aime pas le méchant capitalisme?!). Note qu'ils ont proposé et implémenté Jingle, ça marchait bien, mais ça a été amélioré et Google n'a pas dit "non, vous ferez comme nous, et c'est tout" comme tu l'affirmes. Non ils ont pris leurs développeurs et ils leur ont dit: "ok le standard a changé, s'il vous plaît, mettez à jour en suivant les recommandations de la XSF" (d'ailleurs cela était reproché dans l'autre sens car justement Google était pas encore à jour. Comme quoi, les gens sont jamais contents: si on avait suivi à la lettre sans rien revoir le protocole de gtalk, on aurait dit qu'on est vendu à Google. Mais si on améliore le protocole, c'est nul "y a 2 Jingle" -> cf. remarque qu'on m'a faite sur le dernier billet). Il n'y a pas de domination de Google sur la XSF qui est et restera purement neutre. Dans une spéc comme Jingle, il y a eu énormément de contribution hors-Google.

Mais sinon de manière générale, oui tu as raison. Google arrive et met un peu des coups de pieds dans une fourmilière de débats (pas forcément des débats stériles ceci dit) et s'impose avec son nombre utilisateur. Bienvenue dans le monde des Standards. Mais toi tu fais paraître cela comme une très mauvaise chose. Ça ne l'est pas.
Si tu travailles un peu en entreprise, tu sais sûrement comment ça se passe: on développe des trucs dans l'urgence, on mets les bugs sous le tapis plutôt que les corriger, on fournit du support langue-de-bois, on fait des trucs qui "marchent" en effet dans la plupart des cas, mais on laisse de côté des trucs inutiles comme l'interopérabilité, les cas spéciaux chiants qui font 1% de nos utilisateurs, on prend des technologies spécifiques pleines de brevets et qui ne marchent pas sur toutes les plateformes, etc. En gros on fait les trucs mal, mais qui donnent le change, et surtout avec une implémentation.

Par contre les organismes de standard, c'est une coquille vide à la base, avec des règles pour faire tout ce que les entreprises ne veulent pas faire. Et les gens qui remplissent la coquille sont soit des "standardiseurs" purs et durs (des mecs qui font bcp de théories, lisent les standards à la pelle, et participent à 50 groupes de travail, etc. mais n'implémentent pas), quelques gens qui font des projets logiciels (éventuellement en hobby) et ne participent qu'aux 3/4 standards qui les intéressent, et… les entreprises. Ces dernières y gagnent tout ce qu'elles ne savent pas faire bien. Donc en effet, c'est tout à fait ça: les organismes de standard sont pour ces entreprises des « service[s] d'optimisation et validation pour [leur protocoles]». Elles y gagnent cela. De notre côté, les standards y gagnent la réactivité des entreprises qui ont des gens payés pour travailler à temps plein sur ces protocoles et qui doivent faire les choses rapidement pour battre la concurrence. Sans eux, effectivement, il y a soit des nouveaux standards qui sont tellement géniaux, ou qui manquaient tant jusque là, que leur implémentation partout s'impose (extraordinairement rare), soit beaucoup de disputes pour des standards ou des approches différentes. Mais au final ce qui compte, ce sont les implémentations. C'est ça qui décide réellement qu'un standard passe un stade du "vent" au "réel". Et bien que ces implémentations peuvent être des projets hobbyistes, les "gros chiffres" sont en général faits par les entreprises qui y mettent des moyens. Donc ils implémentent ce qu'ils estiment être le mieux (pas forcément ce qu'ils ont développé; souvent ils choisissent un des "combattants" dans les débats contradictoires et ça clôt le débat).
Les vrais gagnants dans tout ça, ce sont les utilisateurs. Et c'est ça l'important.

Enfin dernier point si on ne voit que Google, c'est que ce sont la seule entreprise de cette taille qui participe à la XSF autant, mais on n'attend que cela que les autres viennent (peut-être bientôt AOL? Facebook, ils font que parasiter, mais pour contribuer, on attend toujours, etc.). Mais de manière générale, on ne profite pas que d'eux. Par exemple, je parlais plus haut de Skype, qui en un sens aide aussi XMPP en participant à SILK et OPUS que l'on se privera pas pour utiliser également (pareil, pourquoi ils contribuent IETF et font ami-ami avec xiph.org et d'autre au lieu de faire dans leur coin? Parce qu'ils se rendent bien compte que ça leur apporte beaucoup plus de travailler ainsi).

Ce que j'essaie d'expliquer, c'est un peu comment ça marche en interne, quelle est la "vie" d'un standard, quel est le processus pour créer la colonne vertébrale du net, que sont ces organismes que vous semblez tous exécrer comme un ramassis de brasseurs de vent. Les organismes de standardisation (que ce soit XSF pour l'IM, W3C pour le web ou l'IETF pour l'Internet en général) sont lents, chiants, trollifère, mais ils fabriquent des choses qui durent. XMPP n'a fait que progresser tranquillement depuis 12 ans. En fonctionnalité, en implémentation, et en part de marché. Les autres, c'est du vent marketing. Ils vont et viennent. Ils font du "buzz", puis on les oublie. Ils se vendent entre eux, se prostituent, atteignent des sommets… pour chuter sans préfixe "para". Les standards, eux, progressent. Et c'est tout.
C'est vrai pour le web (il y a les "alternatives proprios" qui ont leur heure de gloire à coup de milliards puis leur déchéance), pour l'IM, pour tout.

Pour les réactions émotionnelles, sachez qu'ici, il est passé 0h00 et on est déjà le 8, voilà!

Moi il est 4h30 et aussi le 8.

Moi j'attends toujours de pouvoir recommander XMPP à mes parents sans m'entendre répondre que leurs potes en ont jamais entendu parler mais ils sont sur msn ou Skype.

Pour ma part, j'attends que les gens arrêtent de parler de XMPP et de troller sur le nom ou l'inconnu de ce nom. Personnellement je parle aux gens uniquement de "messagerie" ou "messagerie instantanée". Parce que l'avenir est simplement dans l'interopérabilité. Déjà on travaille pour rendre XMPP et SIP intéropérable et il m'est avis que les sociétés qui vont progressivement se mettre à XMPP vont dans un premier temps faire des passerelles en gardant leur protocole proprio en interne. Mais cela n'importe pas. Je veux juste pouvoir demander à quelqu'un son adresse IM, l'ajouter à mon roster et le contacter ainsi, sans me préoccuper de son fournisseur et de la technique derrière. Et cela n'arrivera pas tant qu'on fera des distinctions qui n'importent qu'aux techniciens.

Et mieux: héberger un serveur en [notre-nom-de-famille].com/perso/autre

Bah va y, fais le! :-) Avant même d'avoir un serveur auto-hébergé, tu peux même gratuitement utiliser les services de l'APINC qui te fournit son serveur XMPP avec ton propre domaine: http://jabber.apinc.org/

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

faudrait trouver quelqu'un qui bosse ou a bossé ds l'industrie télécoms pour répondre mieux. En tous cas, si la question est de savoir s'ils utilisent d'autres codecs que G.711, bien sûr. Ils évoluent comme tout le monde. Mais je pense que G.711 est simplement l'un des plus vieux, et donc est choisi comme "codec obligatoire" dans toute nouvelle technologie de communication audio (ce qu'on a aussi fait très récemment, comme je l'indique dans la dépêche). Le but de cela n'est pas de lui donner la priorité mais simplement que quelque soit le réseau que tu vas utiliser (les lignes de cuivre historiques, les quelques variantes de téléphone numérique, les foultitudes de réseau mobiles, etc.), au final on a toujours G.711 comme solution de secours (donc tous les réseaux sont compatibles).

En gros, si tu appelles quelqu'un, soit il y a un maillon faible (par exemple l'un des deux est sur un bon vieux fixe), soit vous êtes sur deux technologies différentes, toutes deux avec des codecs haute qualité, mais pas les mêmes, donc vous retombez sur votre seul codec commun: un codec d'il y a 40 ans.

Aussi quand on y pense, la communication peut passer par des passerelles. Par exemple supposons un appel Jingle, qui utilise Speex ou autre codec voix haute qualité. Supposons que tu appelles un téléphone qui peut aussi utiliser le codec Speex (d'après Wikipedia, la recommandation H.323 est utilisée dans des réseaux 3G ou les lignes numériques ISDN par exemple et a apparemment des implémentations avec Speex). A priori tout va bien. Mais voilà, tu passes par une passerelle qui lie ton serveur XMPP à un fournisseur télécom (avec qui il y a un contrat pour que les utilisateurs puissent accéder au réseau tél classique), qui elle ne peut faire passer que du G.711 (a priori d'après ceux qui disaient bien connaître sur la ml IETF, il y a bcp de passerelles qui ne connaissent que ce codec). Dc bah j'imagine que dans un cas comme cela, tout le monde retombe sur ce codec commun alors qu'à chaque bout, vous aviez en commun un bien meilleur codec.

Et je pense qu'on se débarrassera pas facilement de G.711, ne serait-ce parce qu'il y aura les lignes cuivre pour un bon moment (même si elles perdent du terrain avec le sans-fil) et qu'on ne doit pas casser la compatibilité.

Note que toute ma réponse n'est que le reflet de ma propre compréhension du sujet, qui est basée sur une connaissance minime. Je ne bosse pas dans l'industrie télécom, et n'ai jamais eu à travailler sur une connexion entre un réseau VoIP et les réseaux télécoms. Ma propre participation sur ce sujet précis dans les listes consiste essentiellement à lire ce qu'écrivent ceux qui disent savoir (et quand je répondais sur le sujet des codecs audio par exemple, ce fut essentiellement pour synthétiser les diverses choses que les autres ont écrites et essayer de dégager un consensus pour faire avancer les choses). Donc en gros, j'y connais rien et je peux me planter. Tout apport de connaissance par quelqu'un qui travaille dans le milieu est bienvenu.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je ne saurais répondre à la première question. Je ne compare pas beaucoup les clients dernièrement.
Note que j'essaie de préparer un évènement interopérabilité qui permettra de tester massivement (avec l'aide d'utilisateurs et la collaboration des développeurs) les clients. Le but d'un tel évènement n'est pas de montrer du doigt ou de trouver un "gagnant" mais de trouver ce qui ne va pas dans les implémentations actuelles, de rassembler de l'information de debug massivement sur des environnements hétérogènes (les utilisateurs aléatoires du monde) et de les corriger. Néanmoins ça permettra quand même de voir les implémentations qui se comportent le mieux. Ensuite faut arriver surtout à motiver les diverses équipes de clients, puis organiser cela, etc. En gros ce sera pas avant quelques mois. Si jamais ça se fait, je ferai une news sur linuxfr.

Pour OPUS, aucune idée non plus, mais au hasard, je dirais "personne". C'est extrêmement récent. Si tu regardes la spéc, le brouillon le plus ancien date d'octobre 2010 (et si tu remontes dans des brouillons d'autres propositions liées, c'est à peine plus vieux, mi 2010). OPUS se base sur SILK contribué par Skype et CELT de xiph.org. L'un comme l'autre sont à l'état de brouillons IETF également (les deux ayant leurs premières versions en début 2010). Et le tout est activement modifié. C'est donc une spéc instable d'un codec, basée elle-même sur plusieurs codecs, eux-même instable, le tout en plein développement.
En gros, on peut utiliser ces spécifications pour commencer à développer, faire des tests, s'émerveiller du futur, mais il ne faut pas considérer cela comme stable et surtout pas dans un espoir d'interopérabilité immédiate en espérant que deux implémentations différentes seront compatibles.

Mais je ne dis pas ça pour dissuader quiconque de commencer à implémenter, hein. Les premières implémentations/expérimentations essuient certes les plâtres, mais aussi permettent d'avancer le plus rapidement l'écriture de spécs et aussi d'améliorer ces dernières qualitativement (en pratique, on tombe tjrs sur des choses auxquels on ne pense pas si on se limite à de la réflexion théorique).

Aussi même si OPUS est créé dans une optique ouverte (car IETF) et qu'il n'y a donc pas à douter que la version finale sera libre de brevets, il semblerait qu'il y ait eu des réclamations de brevet logiciel sur le brouillon d'OPUS actuel (déjà!), comme je l'ai dit dans la dépêche. Donc déjà ça peut prendre du temps avant de démêler tout cela, d'autre part, ça peut être une raison majeure pour changer certaines parties d'une spéc (ça dépend de chacun, mais parfois il est plus simple de contourner les difficultés, surtout certaines aussi débiles que les brevets, que de se battre contre des moulins).

Note: la liste des IPR (Intellectual Property Rights) d'OPUS est là où on voit que Broadcom, Skype et Xiph.org abandonnent leur droit de poursuivre (pour violation de brevet) pour cette spéc (si je lis bien). A priori le seul IPR agressif est celui de Qualcomm, qui dit «Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee.»

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

je ne suis pas un expert de ces sujets, mais théoriquement oui tout est possible. D'ailleurs c'est notamment pour ce genre de chose que les plateformes de télécoms classiques rentrent dans nos critères de décision (par exemple dans la dépêche pour le choix de notre codec audio "de base"). On améliore nos points de compatibilité pour pénétrer le marché télécom.

Ensuite dans la pratique, ça dépend déjà beaucoup de l'industrie des télécoms. Eux se sont habitués à SIP qui fut premier sur le marché et donc toute leur infrastructure logicielle pour relier les réseaux VOIP et télécoms est basé aussi sur SIP. Cela signifie deux choses:

(1) Soit XMPP prend vraiment de plus en plus d'importance dans le monde de la VOIP (et c'est possible), et les télécoms se mettront donc à s'y intéresser et à travailler avec nous (directement ou non) pour interfacer aisément un appel Jingle sur un appel "physique". Si cela arrive cependant, il y a presque forcément une certaine latence, comme pour tout dans les grosses entreprises qui sont plutôt réactives que pro-actives (et donc réagiront en panique quand ils voient que XMPP prend le dessus et que SIP disparaît par exemple, plutôt que se préparer en avance).

(2) Soit nous nous adaptons aux interfaces actuelles en créant des passerelles XMPP vers SIP (puis la communication "traduite" SIP s'interface elle-même dans une passerelle télécom).
C'est en fait ce qui se fait actuellement. C'est ainsi que marchent les appels gtalk vers des lignes physiques, en passant par une passerelle SIP (si je ne me plante pas).

Idéalement évidemment dans ma position, je préfèrerai le point (1), mais le point (2) est plus probable, au moins à court terme. Peut-être plus tard verrons-nous apparaître un mélange des deux possibilités (et à terme le cas (1) seulement si XMPP l'emporte totalement en utilisation sur SIP, ce qui ne me paraît pas improbable, voyant la tendance actuelle).

Pour les deux projets que tu cites, le P2PSIP n'a plus de nouvelle sur le site depuis 2009. Il semble par contre y avoir de l'activité récente de soumission de rfc à l'IETF mais relativement peu de discussion donc une communauté assez absente (et donc pour l'instant sans communauté ni allié fort…). Ensuite sinon techniquement je connais pas, et j'ai pas creusé. Ça se repose sur le réseau actuel SIP (c'est à dire: est-ce compatible avec l'existant?) ou bien c'est un nouveau protocole/réseau incompatible (et le nom, c'est juste pour dire que ça reprend des idées)? Parce que si c'est une tentative de créer un troisième réseau, ce ne sera pas simple avec la concurrence de SIP et XMPP.

Quant à Gnutelephony, je pige pas trop ce que c'est (j'ai pas poussé non plus beaucoup). Ça parle aussi de téléphonie p2p, mais en même temps de serveur (donc pas si p2p, ou en tous cas, pas pleinement). En fait, j'ai surtout l'impression que c'est un projet dont le but n'est au final que de promouvoir le serveur GNU SIP Witch (donc une implémentation serveur SIP). Ou bien y a-t-il autre chose que je ne vois pas?

Bon désolé, en gros je connais pas tes projets, mais bon c'est du SIP, donc déjà c'est pas mon domaine. Je n'ai pas la connaissance pour en dire beaucoup plus.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Aussi ICQ et AIM sont en fait le même réseau (réseau du protocole OSCAR). Tu peux par exemple déjà contacter un utilisateur AIM depuis un compte ICQ et vis-versa. La conséquence, c'est que si jamais AOL va au bout de sa démarche d'ouverture (je l'espère en tous cas), les numéros ICQ devraient être totalement interopérables (sauf s'ils mettent une limitation virtuelle, mais s'ils s'ouvrent au standard, ils n'ont pas de raison de mettre des bâtons dans les roues des comptes ICQ) avec un compte IM standard. J'imagine que l'adresse associé sera du genre @aol.com et on pourra les contacter et les ajouter à nos listes comme on contacte n'importe quel autre compte du réseau Jabber de sa liste.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

merci donc à Xavier et Claudex pour la reprise en dépêche.

En fait je n'avais pas proposé en dépêche parce que:

1. la dernière dépêche que j'ai proposée (qui était bien plus courte car sur une nouvelle précise) m'avait été rejetée et qu'en plus je n'ai pas apprécié certaine remarques faites dessus alors que je m'étais aussi appliqué pour la rédiger avec un plan, une information objective, puis analyse subjective et donc appel à discussion/troll. Le plus ironique est que la nouvelle rejetée en question est contenue dans cette dépêche-ci (il s'agit de la partie sur AOL sur la dépêche présente, qui est globalement partiellement reprise de la news que j'avais rédigée à l'époque). Donc je n'ai pas eu envie de reproduire l'expérience (d'ailleurs ça m'a un peu dégoûté pour quelques temps, je retenterai pas tout de suite), donc j'ai simplement fait un journal. Notez que ce sont les remarques reçues plutôt que la réjection en soi (d'ailleurs si je me souviens bien, je crois bien avoir déjà eu au moins une nouvelle rejetée y a longtemps et ça ne m'avais pas choqué à l'époque) que j'ai trouvé décevant.
2. je ne trouve pas que mon texte était suffisamment bon pour un texte de première page (au niveau syntaxe/rédaction). J'ai bien sûr passé quelques heures pour rédiger cela, mais il me reste des fautes que je n'ai vues qu'après publications, des tournures dont je ne suis pas content, des répétitions, des parties que j'aurais retouchées ou déplacées (par exemple, je me rends compte que "La connectivité" devrait être un sous-titre de "Qu'est-ce qui ne marche pas dans Jingle?"), etc. Je me suis dit que c'était suffisant pour un journal décontracté, mais si j'avais voulu faire une dépêche, j'aurais laissé passer quelques heures encore et relu, et il m'aurait fallu au moins une heure additionnelle de retouche. (en fait j'avais lu le message me demandant de reformater la dépêche pour la première page, et donc j'avais commencé à la reprendre entièrement pour améliorer la qualité avant de proposer, mais vous m'avez pris de vitesse). D'ailleurs j'avoue avoir un peu honte de la dépêche en l'état en première page.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

je vois. Merci pour cette réponse. Cela explique peut-être pourquoi je ne trouve pas de librairie dessus dans mes recherches. Soit parce que tout le monde réécrit (ou recopie si ce sont des licences qui le permettent) directement l'algo (évitant ainsi de créer une dépendance inutile), ou soit parce que les librairies qui l'implémentent implémentent plein d'autres trucs et ne font pas plus de pub que ça sur le fait qu'ils font aussi cet algo simple vieillissant.

Merci pour l'info. C'est parfait.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

En effet.

En fait Benoît Sibaud avait listé, dans un commentaire, les stats du site concernant les JID utilisés et leur pourcentage, ce qui me semblait être utilisé pour déterminer le nombre d'utilisateurs Jabber sur Linuxfr. Donc c'est vrai qu'initialement je réagissais surtout à ça pour dire que certains (au moins moi) n'entrent pas leur adresse Jabber, au moins pour ce genre de raison et donc que ces stats ne peuvent être utilisées pour représenter significativement l'utilisation du réseau IM. D'où le fait qu'il ouvre ce billet suite à mon intervention.

Mais en dehors de cela, c'est vrai que sinon tu as tout à fait raison. Tant qu'on ne fait rien avec l'adresse IM (en dehors la montrer pour ceux qui veulent), il n'y a pas trop de raison de la rentrer dans sa configuration (et donc de la rendre invisible au besoin).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Merci.

C'est vrai que j'aurais pu faire ça moi-même en fait. J'ai rajouté un commentaire dans ton ticket pour préciser ce que je considère vraiment le cœur du problème.

Sinon pour revenir sur les stats. Pour Gmail, tu écris "(ont potentiellement un identifiant XMPP via gtalk)". Mais de mon expérience, je crois que du moment que tu as une adresse Gmail, tu as automatiquement une adresse Gtalk. Mais l'utilisateur ne l'utilise pas forcément. C'est peut-être ce que tu entendais dans ton commentaire (mais bon au cas où, je fais remarquer quand même ce fait).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

puisque le ticket est dérivé d'un de mes commentaires, je donne mon point de vue.
Je dirais que le point important en premier lieu pour moi est de pouvoir avoir l'identifiant XMPP privé. Je ne vois pas pourquoi l'adresse email est par défaut privée alors que celle d'IM est publique (par défaut déjà, mais en plus même pas "privatisable").

Actuellement il est vrai qu'il n'y a pas "trop" de spam/scam sur le réseau XMPP (personnellement je n'en ai jamais eu, mais ça existe déjà un peu. J'ai déjà eu des retours de gens qui en ont reçus) et aussi le protocole est conceptuellement plus résistant aux utilisations malveillantes; mais les tentatives viendront avec le "volume" des utilisateurs, qui d'ailleurs commence à avoir une importance non négligeable depuis que plusieurs gros acteurs rentrent dans le jeu.
Améliorer davantage la résistance au utilisations malveillantes est d'ailleurs dans la feuille de route courante de la XSF.

Pour le reste, ce que Linuxfr fera avec cette adresse, c'est à dire les possibilités d'utilisation avancée, intégrées au site (la messagerie interne est l'utilisation qui vient immédiatement à l'esprit, comme décrite dans ce ticket. Mais il pourrait y avoir bien d'autres utilisations évoluées dans le futur) est pour moi un point secondaire. Cela aurait ainsi pu faire l'objet de deux tickets de suivi:
1/ Rendre l'adresse IM privée par défaut (comme pour l'adresse email actuellement), avec possibilité de la mettre publique pour ceux qui souhaite (case à cocher).
2/ La messagerie interne pourrait utiliser l'IM si cela a été entré par l'utilisateur

Pas besoin d'attendre la fonctionnalité 2/ d'être implémentée pour réparer le bug 1/ (oui, pour moi c'est un peu une sorte de bug de sécurité, ce qui explique que je ne rentre pas mon adresse IM par exemple).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

je voulais juste mettre un bémol sur ces statistiques de Linuxfr. J'ai une adresse de messagerie instantanée mais je ne la rentre pas et ne la rentrerai jamais dans ma configuration Linuxfr tant qu'elle est affichée publiquement, sans choix de la rendre privée.

Je ne veux pas que mon email soit publique, et je vois pas la différence pour mon adresse IM. Je ne souhaite pas que des bots s'empare de mon adresse et me spamme un jour par IM.

En dehors de cela, si Linuxfr se mettait à utiliser Jabber pour me communiquer des informations ou me permettre de faire certaines actions ET que cette adresse n'est pas ainsi publiquement accessible pour être collectée par des bots, je la rentrerais.

Je ne sais pas si il y a beaucoup de gens dans mon cas, mais c'était juste pour signaler que cela pouvait avoir un impact sur les statistiques si vous comptez les utiliser pour savoir le pourcentage de libristes du site qui utilise Jabber.
Bye.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

c'est pas une histoire de meilleur concept. Ce sont juste des conceptions différentes.
À partir de là, je ne crois qu'il y ait besoin de te vendre quoi que ce soit. Et oui bien sûr, on peut se débrouiller sans et oui tout ce qu'on fait dans un concept, on peut le faire dans un autre. Il suffit de voir tout ce qu'ont fait des millions de développeurs dans le monde, qu'ils utilisent une logique impérative, fonctionnelle, objet, déclaratif, etc. en-veux-tu-en-voilà (et avant ça y a des dizaines d'années, des programmes étaient entièrement écrit en assembleur, c'est dire si on peut tout faire quel que soit la "famille" du langage).

Par contre c'est simplement que certains concepts s'adaptent plus aisément à certains problèmes que d'autres.
Par exemple, si je développe un programme où les données rentre, sont traitées, sortent constamment, je vois tout de suite du fonctionnel: t'as une entrée, une sortie et une boîte noire au milieu.
L'objet est vraiment très agréable et permet des designs très "évident" (donc agréable à utiliser) pour tous les problèmes avec des "entités", que l'on peut conceptualiser, qui ont des caractéristiques et qui peuvent effectuer certaines actions.
Etc.

En fait il faut juste voir des classes de problématiques et ce qui permettra de faire la plus jolie et évidente API (soit parce que c'est le but final, ou soit parce qu'on va l'utiliser soi-même). Ça n'empêche pas qu'il y a en fait 1000 autres designs possibles pour la même fonctionnalité et qu'un autre design dans une tout autre logique peut également être très agréable.
C'est juste une question de choix.

Enfin y a la question du langage à utiliser. Personnellement je m'adapte. Quand j'écris en OCaml par exemple, je pense essentiellement soit classe soit fonctionnel. Mes programmes n'auront (presque) jamais la moindre boucle, je préfère les retours de fonctions aux références, et je m'arrange pour que mes fonctions récursives soient toujours terminales (sauf si la complication apportées ne vaut pas le gain. Ça arrive parfois, par exemple pour les fonctions qui auront des appels récursifs peu profond par design).
Si par contre j'écris en C, je fais des boucles, des paramètres par références et du massivement impératif comme tout le monde.
Il faut savoir profiter des forces d'un outil.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

non c'est pas facile. Pour les utilisateurs, tu peux le faire de manière plus ou moins transparente mais c'est pas forcément facile. Si le serveur ne prévoit pas ce genre de cas, c'est à toi de faire le nécessaire, ce qui implique quelques requêtes ds la BDD. Par contre, ça ne peut pas être transparent pour les contacts des utilisateurs par définition. En effet tu n'as pas accès à la base de données des contacts (sauf si tous les contacts de tes utilisateurs sont aussi dans tes utilisateurs bien sûr) et tu ne peux donc pas agir sur leur roster (imagine s'il existait une possibilité pour cela, ça signifierait que quelqu'un pourrait monter un faux serveur et créer des utilisateurs dessus pour "s'emparer" des utilisateurs d'autres serveurs, et ce de manière totalement invisible, donc il serait capable de faire des attaques ciblées en se faisant passer pour d'autres).
En conclusion, ce n'est pas la bonne solution.

Une solution pourrait être que tu pourrais envoyer des notifications de "déménagement" pour tous les contacts de tous les comptes utilisateurs (XEP-0283, l'extension expérimentale qui existe actuellement et implique que les contacts devront approuver manuellement le changement, par rapport à ce que je disais précédemment sur les problèmes de sécurité). Mais je ne sais pas exactement quels clients implémentent réellement cette XEP. Je ne la connais pas trop non plus, mais je pense qu'elle pourrait être vraiment améliorée pour être rendue plus transparente, tout en étant sécurisée. J'y jetterai peut-être un œil un jour.

Ma conclusion cependant serait que je ne te conseille pas de le faire de manière trop transparente. Déjà simplement parce que tes utilisateurs devront bien savoir que leur adresse a changée pour la donner aux gens. Ensuite parce que s'il y a des problèmes parce que des contacts n'ont pas pris en compte le changement (leur client ne supportait pas la XEP "moved" par exemple), ben tes utilisateurs pourraient ne pas s'en rendre compte immédiatement et simplement croire que tel ou tel contact ne se connecte plus pendant longtemps. Alors que s'ils sont bien informés, ils sont conscients que des problèmes peuvent survenir et donc être proactifs (rentrer en contact avec certains utilisateurs pour s'assurer qu'ils se mettent à jour).

Mon conseil:
1/ utilise la nouvelle adresse pour les nouveaux inscrits, mais garde l'ancienne en parallèle par défaut sans transférer personne. Un nouvel inscrit ne peut se faire par contre que sur la nouvelle.
Par contre informe tes anciens utilisateurs qu'une nouvelle adresse est disponible. 2/ réserve tous les nicks sur la nouvelle adresse qui existent déjà sur l'ancienne. Et fais savoir à chaque utilisateur que s'ils décident de "déménager", leur nick leur est réservé aussi longtemps qu'ils ont leur ancien compte. 3/ si un utilisateur désire déménager vers la nouvelle adresse, prépare tout pour lui faciliter la tâche le plus possible. Par exemple, il a juste un clic à faire sur une page (ou un bot XMPP à qui il envoie un message), ce qui génère automatiquement des stanzas de déménagement pour tous ses contacts, ainsi qu'envoie des autorisations à tous ses anciens contacts pour son nouveau compte). 4/ L'utilisateur qui déménage devrait garder un accès à son ancienne adresse un certain temps (6 mois?), ce qui lui permettrait de gérer les contacts qui ne supportaient pas la XEP-0283 et donc n'ont pas inscrit le nouveau JID (l'utilisateur a donc besoin de son ancienne adresse pour voir quand ils sont connectés, discuter avec eux et leur dire qu'il a changé si besoin par exemple) ou gérer les gens à qui il aurait récemment donné son ancien JID et qui inscriraient ce dernier. Et autre...

Et il faut savoir que tout type de migration a toujours son lot de problème. Mon expérience là-dedans, c'est qu'une bonne communication pour prévenir de cela vaut mieux qu'essayer d'être le plus discret possible (transparent) car lorsque les utilisateurs s'en rendent compte (car ils s'en rendront compte, et certains auront des problèmes), ils seront furieux. Alors que si tu leur laisses le choix en les prévenant des risques sur le court terme mais des avantages sur le long terme, ce sera un choix conscient de leur part, donc ils prennent leur part de responsabilité!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

bien sûr que c'est possible! J'en parle même dans mon article!
Je cite un organisme qui propose ce service (payant): Google avec les Google Apps.

Beaucoup plus proche des libristes, l'Apinc (Association pour la Promotion de l'Internet Non Commercial) aussi propose le même service gratuitement: http://jabber.apinc.org/. Je suis un peu bête d'avoir oublié de parler de leur service (n'hésitez pas à ajouter ce lien à la dépêche!). Ce genre de service se démocratise de plus en plus et leur sécurisation est un de nos gros sujets du moment (cf. l'article et je détaille plus bas dans ce post).

L'un comme l'autre te permettrait d'avoir ton jid comme toi@tondomaine.fr, et ce sans que tondomaine.fr redirige vers quoi que ce soit d'autre que ton site web dans un navigateur.
J'explique même comment ça marche dans l'article (même si c'est vrai que je n'ai pas détaillé, car si je détaille tout, l'article est trop long, un reproche qu'on me fait souvent): on utilise les DNS SRV records.

Les ancêtres

La vieille méthode que http utilise encore, c'est effectivement juste de rediriger un domaine vers l'adresse principale qui lui est dédiée (ce qu'on appelle un enregistrement A pour IPv4 et AAAA pour IPv6. Il existe chez Mozilla un rapport de bug depuis 11 ans et demi pour utiliser les SRV et ne passer aux A/AAAA qu'en fallback, auquel je suis abonné moi-même depuis quelques années et qui a beaucoup de votes, d'abonnés, et a même eu des patchs envoyés par certains, mais Mozilla ne semble pas intéressé alors que le service http a déjà été enregistré par l'IANA).
Mais ça c'est la méthode antique, aucune flexibilité.

La relêve (actuelle)

Les enregistrements de service, c'est bcp plus subtil. On fait un enregistrement DNS qui dit quelles IPs regarder pour tel "service". Nous, on a deux enregistrement de service principaux: xmpp-client ou xmpp-server (selon qu'on parle au client ou serveur).

Une entité fait donc une requête DNS pour le domaine concerné du service désiré, et ça retourne une liste de couples (IP, port) à utiliser. Ça permet de préciser quelles IPs hébergent ton service Jabber et sur quel port (je connais au moins 2 serveurs qui n'utilisent pas le port par défaut sans aucun problème de fonctionnement alors que les services web doivent utiliser un truc moche à la example.com:8888 pour faire pareil), qui peut tout à fait être différent de ton serveur web.
Note que pour les petits organismes avec plusieurs serveurs mais sans beaucoup d'argent, ou sans tout une équipe d'administrateurs dédiés à l'infrastructure, SRV permet aussi un répartition de charges statique (donc basique mais suffisante pour beaucoup de petites et moyennes structures). Les enregistrements possèdent en effet un système de priorité et poids à utiliser conjointement pour se connecter aléatoirement (avec préférence) sur des machines différentes d'une utilisation à l'autre.
Un enregistrement normal (A/AAAA) n'a pas d'équivalent de ce système de répartition de charges car au mieux, on mélange les enregistrements A/AAAA aléatoirement (ils ont donc tous le même poids, on ne peut préciser les probabilités de connexion souhaités selon la machine, ce que fait SRV).

Donc oui, c'est possible, c'est même facile à faire. Ça demande des compétences très basique pour quiconque a les compétences de base pour avoir son propre domaine (c'est presque pas de l'administration info tellement c'est facile).
1/ tu t'inscris sur le service qui va héberger ton serveur.
2/ tu ajoutes un enregistrement DNS (pour ceux qui n'hébergent pas leurs propre serveur DNS, c'est en général simplement dans l'interface web de ton registrar) et tu ajoutes un (ou plusieurs si le service qui t'héberge a plusieurs machines) enregistrement de service xmpp-client et xmpp-server.

Et... c'est fini! XMPP fait ça depuis des années. En fait c'était déjà standard dans la RFC3920, comme je le dis dans l'article, donc on fait tous ça depuis au moins... 7 ans!

Google ne se gêne pas pour utiliser tout cela pour ses 5 machines XMPP client (et il a 5 machines xmpp-server différentes pour le même domaine):

$ ring -t SRV _xmpp-client._tcp.gmail.com
gmail.com. has a xmpp-client service record on tcp:
	priority  = 20
	weight = 0
	port = 5222
	target = talk4.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
	priority  = 5
	weight = 0
	port = 5222
	target = talk.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
	priority  = 20
	weight = 0
	port = 5222
	target = talk1.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
	priority  = 20
	weight = 0
	port = 5222
	target = talk2.l.google.com.
gmail.com. has a xmpp-client service record on tcp:
	priority  = 20
	weight = 0
	port = 5222
	target = talk3.l.google.com.

Bien sûr certains font encore la vieille méthode avec un enregistrement A et/ou AAAA sur un sous domaine de leur domaine principal. Genre im.example.com. Perso j'ai jamais compris pourquoi! Je ne connais pas un client ni un serveur de nos jours qui ne gère pas les SRV records. Et au final c'est plus compliqué car on doit créer et gérer un nouveau sous-domaine.

Le futur

Enfin la seule problématique avec cette solution est la sécurisation par certificats X509 (TLS). Les possesseurs d'un domaine n'aime pas toujours donner un certificats pour leur domaine principal à un service tier, et ça peut se comprendre (le service tier, si malveillant, aurait alors le pouvoir — presque officiel — pour se faire passer pour le domaine principal pour d'autres types de service, comme le web).
Il est en réalité possible d'associer un certificat à un enregistrement de service (il y a au moins un CA qui propose ce genre de certificat), mais malheureusement à ce que j'ai compris les navigateurs web (encore eux!) ne regardent pas vraiment ce champs et donc cette sécurité passe à la trappe à l'heure actuelle. C'est pourquoi (encore comme je le dis dans l'article! J'explique trop mal?) pas mal de gens réfléchissent à une solution pour rendre ce passage de pouvoir à la fois aussi sécurisé que si on le faisait nous-même mais sans donner les pleins pouvoirs sur tout le domaine. Y a au moins un brouillon de RFC proposé sur le sujet (mais je l'ai pas encore lu, je ne connais pas sa pertinence).

Et après j'en lis plus haut que XMPP est une vieux truc alors qu'on est parmi le top de la technologie Internet (on est parmi les premiers à utiliser les technologies les plus récentes. SCRAM par exemple, XMPP est LA technologie qui fait vraiment démarrer ça et comparé aux vieux mécanismes SASL, c'est vraiment génial. SRV aussi, nous sommes parmi ceux qui ont créé une adoption massive; bien que sur le coup, je crois que SIP était avant nous) et qu'on est constamment à innover sur tous les fronts et à prendre des risques en adoptant des technologies avant les autres. Alors bien sûr on cherche aussi la rétrocompatibilité en même temps. Mais après si on cassait l'intéropérabilité entre les serveurs récents et anciens, vous iriez encore vous plaindre (et un peu plus à raison pour une fois)!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Bonjour,

1/ pourrait-on mettre à jour les liens RFCs? Je pensais qu'ils resteraient un peu, mais les liens donnés étaient en fait les liens dans la dernière phase du processus de standardisation (qui s'est stabilisé aujourd'hui, bien que les versions données étaient déjà les versions finales qui n'avaient quasiment aucune chance d'être modifié dans cette étape avant le statut final).

Les bons liens sont donc:

http://www.rfc-editor.org/rfc/rfc6120.txt http://www.rfc-editor.org/rfc/rfc6121.txt http://www.rfc-editor.org/rfc/rfc6122.txt

Ou encore, je préfère personnellement utiliser:
http://tools.ietf.org/html/rfc6120 (etc. 6121, 6122)
parce que c'est du html avec hyperliens dans les menus (et qu'on peut aussi avoir la version txt ou pdf à partir de là).

2/ Aussi pourriez-vous modifier aussi le "TLS EXTERNAL" qui est une bête erreur alors que je sais pertinemment que c'est TLS + SASL EXTERNAL. Ça m'évitera d'avoir honte. ;-)

Je donne aussi l'astuce aux gens intéressés dans les RFCs et dans l'utilisation avancés d'un navigateur web aussi: dans Firefox (et je pense dans le plupart des concurrents, y a un équivalent), vous pouvez enregistrer un bookmark de la sorte: http://tools.ietf.org/html/rfc%s Et vous mettez un "keyword", par exemple "rfc". Puis dans votre barre d'adresse, vous tapez juste "rfc 6120" et paf! Vous êtes direct dans la bonne rfc! C'est ce que je fais personnellement pour naviguer rapidement d'une RFC à l'autre.

Vous pouvez adapter cette astuce à tout type de site qui utilise des URL "parlantes" et simples (comme quoi, c'est important de penser l'architecture des URL!).

Merci.

Jehan

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

je vais répondre aux divers points:

1/ le nom: je suis d'accord, le choix du nom n'est pas terrible pour le grand public, c'est sûr. Mais c'est uniquement un choix "technique" de nom pour un protocole. Cela n'implique pas qu'on souhaite que les utilisateurs se mettent à l'utiliser (pas moi en tous cas).
Les utilisateurs disent-ils "je vais regarder sur le web" ou bien "je vais consulter des pages html par http"? Disent-ils "tiens je t'ai envoyé un email!" ou bien "Je t'ai envoyé un message par smtp, l'as-tu reçu par pop/imap?". Etc.
De manière général, il faut différencier le nom d'un protocole et son utilisation. C'est juste un nom technique (de même que je suis sûr que les voitures ont un nom technique et ridicule avant d'avoir un nom sexy pour passer en publicité, de même pour la plupart des projets!), faut arrêter de se focaliser dessus. Jabber est toujours un très bon nom, utilisable et le nom du serveur publique géré par la XSF s'appelle toujours jabber.org et personne ne parle de changer ce nom.

Pour ma part, je préfèrerais qu'on utilise le nom générique de "messagerie instantanée" et qu'on oublie un instant le nom des protocoles. Avec le travail d'intéropérabilité avec SIP, ça sera d'ailleurs d'autant plus vrai. Qu'importe le protocole derrière, on a une adresse qui permet de discuter, on s'en fiche du reste.

2/ Je suis triste aussi que Facebook ait décidé de ne pas ouvrir ses serveurs, mais ça ne m'étonne pas plus que cela de cette entreprise. Ils ont aussi fermé leur réseau web, tu sais. On ne peut pas regarder les pages Facebook sans compte (moi j'ai jamais pu en tous cas). Ben ils font pareil avec Jabber qu'ils ont fait pour le web. Est-ce que tu vas te plaindre aussi que le web c'est nul parce qu'y a des serveurs fermés comme Facebook?

3/ Les extensions, ce sont comme des RFC, sauf que c'est au niveau de la XSF au lieu de la IETF. Donc on a aussi un protocole de standardisation. Ainsi les extensions commencent avec des statuts expérimentals, elles sont testées, implémentées, modifiées. Et parfois elles passent au stade de standards XSF. Parfois elles sont abandonnées. Parfois certains font leurs extensions dans leur coin pour une utilisation privée (réseau d'entreprise, ou autre) sans intention de standardiser donc de proposer une XEP. Y a de tout.
Encore une fois, va voir combien de brouillons de RFC sont proposés à la IETF, le nombre de brouillons que cela a impliqué (on a 23 brouillons entre la RFC 3920 et 6120, et 21 pour 6121!), et combien passent en standard quand la plupart passent aux oubliettes. Vas-tu dire que la IETF pue parce qu'ils permettent tant de versions expérimentales?

4/ Il n'y a qu'un standard Jingle. Le fameux "Jingle by Google" n'existe pas. Ils ne se sont simplement pas mis à jour encore avec la version standardisée, c'est tout. Mais ils y viendront, comme tout le monde qui veut implémenter la VOIP par XMPP. Ils n'ont aucun intérêt à ne pas le faire.
Je rappelle que c'est Google qui a fait la proposition de Jingle, ils ont donc la plus vieille implémentation expérimentale du protocole. C'est sûr, c'est plus facile quand le protocole existe déjà. Eux, il n'existait pas. Ils ont expérimenté, ont proposé un standard, ça a été étudié, discuté, et on l'a standardisé.
C'est ce que je disais dans l'article: pour l'instant tout le monde a une version de base, plus ou moins complète, basée sur une version plus ou moins expérimentale du protocole selon quand ils ont commencé à implémenter (avant que le protocole soit fixé ou après). On attend donc juste que tout ça se tasse et que les diverses versions se mettent à jour. Ça prend le temps qu'il faut mais ça viendra.

Mais sinon, non: il n'y a qu'un Jingle.

Pour SIP, c'est différent. Y a eu tentative de standardisation de deux protocoles qui à l'origine était finalement assez différents: l'un était vraiment orienté texte (XMPP), l'autre voix (SIP). Au final, avec le temps et les évolutions, les fonctions ont commencé à se recouper puis de plus en plus. Mais c'était trop tard, les deux protocoles étaient déjà standardisés et avaient chacun une grosse masse utilisateur. C'est pas comme si quelqu'un va se mettre à vouloir dire "ok ben finalement on révoque un des deux protocoles". Donc on fait avec et maintenant seul le temps peut nous dire si l'un des deux protocoles va prévaloir ou si les deux vont coexister ainsi pendant encore longtemps.
Et donc faire avec, c'est ce qu'on fait avec les discussions sur l'intéropérabilité entre les deux réseaux (voir la liste de discussion SIXPAC (SIP Interworking with XMPP in Presence Aware Clients) de l'IETF).

Note au final qu'il y a encore un autre cas où plein de technologies très différentes intéropère. Et c'est aussi dans les télécoms, on appelle ça le téléphone! Entre le RTC, d'autres variantes numériques fixes, et une foultitude de protocoles différents pour le mobile (GSM, GPRS, 3D, etc. En veux-tu en voilà)… Ben personne se plaint des téléphones et des protocoles derrière!

Bon bah nous c'est pareil. On arrive pas à rendre les protocoles intéropérables aussi vite que les consortium (ou je ne sais quel type d'organisme) de téléphonie, mais on n'a pas le même argent non plus. Aussi surtout on ne vous demande pas des sommes mirobolantes pour améliorer le système. Mais je trouve qu'on se débrouille quand même bien avec les moyens du bord.
Tu aurais préféré qu'Internet soit un système tout fermé avec des protocoles qu'on paye à prix d'or et géré uniquement par des grosses sociétés?

Voilà pour les divers points.
XMPP n'est pas le protocole parfait. Il a beaucoup de problèmes et il n'y a aucun doute que si les divers acteurs du protocole devait repartir de zéro maintenant, on ferait pas mal de choses différemment. Mais c'est ça le travail de standardisation. On se bat pour faire un système qui convient à tous pour être une norme ouverte, non couverte par des centaines de brevets, et libre d'utilisation pour tous.
Ensuite libre à toi si tu trouves que c'est de la merde et si tu préfères utiliser un réseau fermé qui a sûrement un nom très sexy, des serveurs très ouverts entre eux-même, aucune extension et une technologie son et vidéo intéropérable avec elle-même.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]