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 ]
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 ]
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 ]
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:
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.
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 ]
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 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 ]
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 ]
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 ]
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 ]
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 ]
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 ]
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 ]
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).
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 ]
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 ]
désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bien que n'ayant jamais testé ton projet, j'avais vu tes divers journaux que tu avais fait dessus, et en fait tu m'avais presque énervé, parce que t'as plein d'idées très similaires aux miennes. ;-)
Quoiqu'il en soit, si ton projet est suffisamment avancé pour être utilisable (parce qu'y a quand même une sélection, on ne peut laisser n'importe quel projet inexistant prendre la place de projet solides) et que tu souhaites aller encore plus loin, tu peux probablement proposer une idée (ou plusieurs même) de projet impliquant SaT, pour lesquels tu pourrais être mentor. Donc SaT pourrait participer au Google Summer of Code sous la tutelle de la XSF. Jette donc un œil au lien donné plus haut.
Bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
comme je disais dans le ticket, même programmé avec les pieds, je suis persuadé que ce sera déjà mieux que Google (qui est vraiment super mauvais pour Linuxfr dans mon expérience, pas vous?), parce que nous avons accès à la structure et logique interne du site.
À partir de là, ça signifie qu'on peut commencer par avoir un moteur de recherche basique fait en 30 minutes (genre on cherche juste la liste des mots en se limitant aux tags, au titre, puis au texte, et enfin on rajoute un bonus aux tickets récents, avec cet ordre de poids: ce sera déjà une grosse amélioration et ça fait quelques lignes de code pour la logique), puis progressivement l'améliorer avec le temps (affiner les poids, rajouter des éléments, créer un systèmes d'options à sélectionner, voire un jour tenter l'expérience d'un moteur de recherche avec apprentissage).
Notez que je suis prêt à aider, mais il me faudrait un environnement de développement déjà prêt. Mon expérience désastreuse lors du concours pour le nouveau site m'a décidé à ne plus essayer d'installer cela moi-même.
Enfin pour les pubs, je comprends. Oui l'idée de tous les ans proposer une campagne de don est intéressante en switchant sur Google search en même temps, et tant que la campagne n'est pas bouclée, semble bien. Aussi n'y a-t-il pas des entreprises qui pourraient sponsoriser Linuxfr (sous et/ou matériel, je crois que les deux se sont déjà faits pour l'assoce, non?)? Je suis sûr que c'est facile, surtout si c'est pas grand chose, parce que vous représentez la source numéro 1 d'informations relatives à Linux et au Libre en France.
Peut-on avoir un ordre de grandeur sur la somme représentée par ces pubs? Quand vous dites que c'est pas grand chose, c'est quoi? 50 euros? 100? 1000?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
cette solution permet-elle de restreindre les droits utilisateurs simples (1)? Par exemple si je veux lancer un programme en m'assurant que ce problème ne puisse pas du tout lire dans le système de fichier (même les fichiers appartenant à l'utilisateur qui fait tourner le programme), est-ce possible?
Ou bien cela permet simplement de donner quelques droits supplémentaires à un utilisateur (qui sont normalement réservés à root), mais pas tous (2)?
Je m'intéresse justement en ce moment à faire la première chose (1) en particulier. Quelles sont les solutions existantes (Capsicum ou autre) capables de faire ce genre de restrictions sous Linux?
Je suis intéressé par tout lien sur la chose ou points de départ pour une recherche. En particulier je souhaite ne pas avoir à modifier un kernel (donc en fait Capsicum, qui m'intéresse dans le concept et peut-être dans l'avenir, n'est cependant pas intéressant pour moi à court terme tant que ce n'est pas un élément de base de Linux).
Merci pour ce sujet intéressant en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel.
Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead).
Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités.
Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent.
Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
I actually think that Direct3D is a rather better API today.
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction cube(l) alors qu'une moins bonne aurait la fonction make_a_regular_hexahedron(d) où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.
C'est cela que l'on appelle une mauvaise API (Interface!) en général.
Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction make_a_regular_hexahedron est vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.
C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Direct3D handles multi-threading better, and newer versions manage state better.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai ball(r). On peut maintenant faire des boules en une ligne de code.
De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant.
C'est en gros, ce qu'ils disent dans l'article là:
While newer versions of OpenGL have kept up-to-date with some of the features found in DirectX, including DirectX 10's geometry shader, they usually have to be implemented via extensions, rather than the main API.
Enfin tout cela est confirmé par:
we wouldn’t get any huge benefits by making the switch, so I can’t work up much enthusiasm for cleaning it out of our codebase.
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Petit état de l'art de (quelques aspects de) la messagerie instantanée. Évalué à 5.
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 ]
[^] # Re: Impressions
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Petit état de l'art de (quelques aspects de) la messagerie instantanée. Évalué à 10.
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.
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).
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.
Moi il est 4h30 et aussi le 8.
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.
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 ]
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Petit état de l'art de (quelques aspects de) la messagerie instantanée. Évalué à 10.
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 ]
[^] # Re: Du concret !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Petit état de l'art de (quelques aspects de) la messagerie instantanée. Évalué à 9.
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 ]
[^] # Re: SIP
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Petit état de l'art de (quelques aspects de) la messagerie instantanée. Évalué à 9.
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 ]
[^] # Re: m'en fout moi j'utilise msn
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Petit état de l'art de (quelques aspects de) la messagerie instantanée. Évalué à 1.
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 ]
[^] # Re: Je ne veux pas faire mon lourd mais...
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Petit état de l'art de (quelques aspects de) la messagerie instantanée. Évalué à 3.
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:
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ITU G.191
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Librairie pour les codecs G.711: PCMU/PCMA. Évalué à 1.
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 ]
[^] # Re: Information privée
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Web -> XMPP/courriel pour la messagerie "interne". Évalué à 2 (+0/-0).
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 ]
[^] # Re: Commentaire auto-centré
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Open Discussion Day ce jeudi 19 mai. Évalué à 1.
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 ]
# Information privée
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Web -> XMPP/courriel pour la messagerie "interne". Évalué à 5 (+0/-0).
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 ]
[^] # Re: Commentaire auto-centré
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Open Discussion Day ce jeudi 19 mai. Évalué à 4.
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 ]
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 4.
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 ]
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 3.
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 ]
[^] # Re: Bataille perdue d'avance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 10.
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):
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 ]
# Requête de mise à jour aux admins
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 5.
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 ]
[^] # Re: Il y a XMPP et XMPP par la réalité
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 10.
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 ]
[^] # Re: TLS external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 1.
Salut,
désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external => SASL external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 2.
Salut,
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Salut à Toi
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 1.
Salut à toi aussi! ;-)
Bien que n'ayant jamais testé ton projet, j'avais vu tes divers journaux que tu avais fait dessus, et en fait tu m'avais presque énervé, parce que t'as plein d'idées très similaires aux miennes. ;-)
Quoiqu'il en soit, si ton projet est suffisamment avancé pour être utilisable (parce qu'y a quand même une sélection, on ne peut laisser n'importe quel projet inexistant prendre la place de projet solides) et que tu souhaites aller encore plus loin, tu peux probablement proposer une idée (ou plusieurs même) de projet impliquant SaT, pour lesquels tu pourrais être mentor. Donc SaT pourrait participer au Google Summer of Code sous la tutelle de la XSF. Jette donc un œil au lien donné plus haut.
Bonne continuation!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Google nous donne des sous
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Avoir enfin un vrai moteur de recherche. Évalué à 3 (+0/-0).
Salut,
comme je disais dans le ticket, même programmé avec les pieds, je suis persuadé que ce sera déjà mieux que Google (qui est vraiment super mauvais pour Linuxfr dans mon expérience, pas vous?), parce que nous avons accès à la structure et logique interne du site.
À partir de là, ça signifie qu'on peut commencer par avoir un moteur de recherche basique fait en 30 minutes (genre on cherche juste la liste des mots en se limitant aux tags, au titre, puis au texte, et enfin on rajoute un bonus aux tickets récents, avec cet ordre de poids: ce sera déjà une grosse amélioration et ça fait quelques lignes de code pour la logique), puis progressivement l'améliorer avec le temps (affiner les poids, rajouter des éléments, créer un systèmes d'options à sélectionner, voire un jour tenter l'expérience d'un moteur de recherche avec apprentissage). Notez que je suis prêt à aider, mais il me faudrait un environnement de développement déjà prêt. Mon expérience désastreuse lors du concours pour le nouveau site m'a décidé à ne plus essayer d'installer cela moi-même.
Enfin pour les pubs, je comprends. Oui l'idée de tous les ans proposer une campagne de don est intéressante en switchant sur Google search en même temps, et tant que la campagne n'est pas bouclée, semble bien. Aussi n'y a-t-il pas des entreprises qui pourraient sponsoriser Linuxfr (sous et/ou matériel, je crois que les deux se sont déjà faits pour l'assoce, non?)? Je suis sûr que c'est facile, surtout si c'est pas grand chose, parce que vous représentez la source numéro 1 d'informations relatives à Linux et au Libre en France.
Peut-on avoir un ordre de grandeur sur la somme représentée par ces pubs? Quand vous dites que c'est pas grand chose, c'est quoi? 50 euros? 100? 1000?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Restreindre les droits utilisateurs ou avoir un utilisateur avec certains droits admins?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 2.
Salut,
cette solution permet-elle de restreindre les droits utilisateurs simples (1)? Par exemple si je veux lancer un programme en m'assurant que ce problème ne puisse pas du tout lire dans le système de fichier (même les fichiers appartenant à l'utilisateur qui fait tourner le programme), est-ce possible?
Ou bien cela permet simplement de donner quelques droits supplémentaires à un utilisateur (qui sont normalement réservés à root), mais pas tous (2)?
Je m'intéresse justement en ce moment à faire la première chose (1) en particulier. Quelles sont les solutions existantes (Capsicum ou autre) capables de faire ce genre de restrictions sous Linux?
Je me suis bien sûr intéressé aux "capabilities" du noyau Linux mais tout ce que je lis (par exemple http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt ) semble indiquer que cela ne permet que la seconde fonctionnalité (2) que j'ai citée plus haut.
Je suis intéressé par tout lien sur la chose ou points de départ pour une recherche. En particulier je souhaite ne pas avoir à modifier un kernel (donc en fait Capsicum, qui m'intéresse dans le concept et peut-être dans l'avenir, n'est cependant pas intéressant pour moi à court terme tant que ce n'est pas un élément de base de Linux).
Merci pour ce sujet intéressant en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Direct3D vs OpenGL. Évalué à 4.
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel. Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead). Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités. Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent. Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Direct3D vs OpenGL. Évalué à 9.
Bonjour,
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction
cube(l)alors qu'une moins bonne aurait la fonctionmake_a_regular_hexahedron(d)où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.C'est cela que l'on appelle une mauvaise API (Interface!) en général.
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction
make_a_regular_hexahedronest vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai
ball(r). On peut maintenant faire des boules en une ligne de code. De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant. C'est en gros, ce qu'ils disent dans l'article là:Enfin tout cela est confirmé par:
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chez moi, ca marche
Posté par Jehan (site web personnel, Mastodon) . En réponse à l’entrée du suivi Raccourci clavier pour venir au commentaire non lu précédent cassé. Évalué à 1 (+0/-0).
Ici Firefox 3.6.11 sous Linux. Ailleurs je sais pas, j'ai pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]