Goffi a écrit 1537 commentaires

On n'est pas obligé d'utiliser leur framework, et d'ailleurs je regrette un peu qu'on l'ait fait parce que si j'avais à refaire ça moi même (ce qui va finir par arriver si on ne trouve pas de bonne alternative), je préférerais être au plus proches du HTML 5.

Le framework à la GWT essaye de masquer le HTML au maximum à coup de tables, et ça fait des pages pas super.

En fait quand il parle « d'overhead » dans rapydscript, il parle surtout (de ce que j'avais compris quand j'avais regardé) du fait que pyjamas cherche la compatibilité Python au maximum, jusqu'aux exceptions qui sont comme en python (super pratique au passage), et c'est parfois au prix de constructions lourdes en javascript. Bon après c'est des options de compilation qui s'activent ou pas, on peut faire un code qui compile en un javascript simple (mais moins optimisé) par exemple.

Le truc aussi c'est que javascript évolue: j'ai assisté à la conf Mozilla sur son futur au dernier Fosdem, et y'a de plus en plus de constructions similaires à ce que fait Python (bon avec une syntaxe dégueulasse), du coup je pense que si on part directement sur Python 3/ECMAscript 6 ou 7, qu'on fait table rase du passé (genre I.E. 6 qui est géré par pyjamas) on peut arriver à un truc potable sans trop de contorsions. En plus maintenant il est possible de lier une ligne de code d'un langage source (donc Python ici) à son équivalent transpilé en Javascript. Bref un Pyjamas aujourd'hui sans l'héritage de GWT serait une solution excellente à mon avis.

En plus Mozilla fourni un outil pour traduire un javascript moderne en l'équivalent plus ancien, pour une compatibilité avec les vieux navigateurs.

Bref, j'aimerais bien avoir le temps de partir dans cette voie.

Pyjamas ne fait pas tourner Python dans le navigateur, il transpile Python en Javascript, d'une part, et fourni une suite logicielle pour développer une application web comme une application de bureau d'autre part. Il est tout à fait possible d'appeler du Javascript avec Pyjamas via JS() également, rapydscript s'en inspire certainement.

C'est très différent de quelque chose comme Brython ou PyPy.js qui eux fournissent un interprète Python en Javascript, donnant une bien meilleure compatibilité au prix d'un chargement long et d'une lourdeur générale.

Pyjamas était un projet très intéressant, malheureusement il a plusieurs problèmes, en particulier:

• quelques défauts de conceptions comme la détection des fonctionnalités à partir du navigateur, probablement héritée de GWT

• il est et restera très certainement bloqué sur Python 2.7

• il a été enlevé de Debian car pyjamas-desktop (qui permettait d'utiliser une appli Pyjamas sans navigateur, en Python natif) ne compilait plus.

• et surtout il n'est plus maintenu suite à un détournement (pas fork, « détournement ») de projet des plus lamentables, cf mon commentaire qui expliquait les grandes lignes

Nous utilisons Pyjamas pour l'interface web de Salut à Toi, et nous avons essayé de le faire revenir dans Debian en contactant l'auteur et l'ancien mainteneur, en supprimant la partie pyjamas-desktop, et en essayant de bouger un peu tout le monde. Le paquet est reparti, mais il a été refusé à cause d'un problème de vérification de licences, et nous n'avons pas eu le temps de relancer la machine, surtout qu'on avait un peu l'impression de se battre contre des moulins à vent, le dév principal semblant débordé. Bref, on perd très bêtement un super projet libre.

Du coup nous avons cherché (et cherchons toujours) des alternatives, et on a vu Rapydscript, mais après une rapide recherche ça ne gère pas Python aussi bien qu'un Pyjamas et ça n'est pas le but si j'ai bien compris (le but n'est pas vraiment de transpiler Python en JS, mais d'offrir une syntaxe « à la » Python, j'ai bon ?). Autrement dit, ça ne peut pas nous convernir a priori comme alternative…

J'utilise Konsole parce que KDEiste depuis des année, et au final je passe mon temps en console, côté graphique je tourne presque uniquement entre iceweasel/icedove (parce kmail foire régulièrement) et akregator.

À côté j'utilise yakuake pour les discussions instantanées (et quasiment que pour ça), parce que c'est super pratique de les voir/masquer en appuyant sur F12.

Non, le problème c'est surtout que tous les sites de news et même de pas news se sentent obligés de faire un article ou autre truc gros comme une maison et lourd comme un chauve,

Ils ne font pas ça parce qu'ils se sentent obligés. Le but n'est pas que ça soit drôle, ou original, le but c'est juste que des liens vers leurs sites circulent, et si possible chez des gens qui n'ont pas de bloqueur de pub. Et ça fonctionne la plupart du temps.

(désolé pour le site lié) on va manger des chips !

Sources non divulgables…

pas besoin de faire des mystères, c'est ultra-connu depuis des années, et faut pas chercher bien loin pour voir comment faire: http://www.instructables.com/id/DIY-Laser-Spy-Microphone/

Les plus anciens ici ont aussi entendu parler de tempest and co, c'est pas de la science fiction.

Mais bon il faut relativiser aussi: si n'importe qui ici voulait espionner quelqu'un lambda je pense qu'il n'aurait pas trop de difficultés à placer un micro quelque part, alors des professionnels avec du matos qui va bien, à l'heure où on peut faire des robots à peine plus gros qu'un moustiques (j'exagère un peu, mais on arrive à faire du vraiment discret), je ne vois pas trop comment on peut se protéger à part se cacher, brouiller les pistes, ou avoir une cage de Faraday avec de quoi détruire toute électronique embarquée à l'entrée (ce qui se fait à l'Élysée par exemple).

D'un autre côté on a vu récemment que quelqu'un qui voulait vraiment se cacher pouvait y arriver aussi, même en étant sur liste noire des personnes à surveiller.

Jusque-là, tout le monde a toujours un peu l'impression que ceux d'en face ne standardisent pas. Pour un développeur non-XMPP, une XEP c'est pas un standard (en tous cas pas plus que la spécification de StatusNet).

Oui enfin XMPP ça passe par l'IETF, y'a des RFC, et le processus pour les XEPs est parfaitement décrit. La plupart des XEPs sont en expérimental ou deferred, et ça n'est pas standard dans ce cas. C'est pas tout à faire pareil qu'un bout de document (je ne sais pas ce qui est dispo pour status.net). Mais une documentation sur le protocole moi ça me suffit, même sans passer par les organismes, et ça déjà c'est très rare en dehors du monde XMPP.

Et si tu veux du microbloggage tout seul et sans boîte, il y avait le Friendika de l'époque qui correspondait assez. Bref, ça existait.

Friendica est toujours là, ainsi que redmatrix, le projet lié.

mais si je veux être un bon citoyen XMPP il faut que je me farcisse une XEP, que je la défende, maintienne, etc.

Non, ça c'est si tu veux contribuer au standard, et c'est un cas plutôt rare

Alors que si je veux contribuer à RedMatrix (pour en citer un que je connais), il me suffit d'aller discuter le bout de gras avec le développeur principal, de faire un pull request, et c'est parti : j'ai contribué et tout le monde en profite.

Ben c'est exactement pareil pour les projets XMPP. Il faut bien différencier standard et projets qui l'utilisent. Vient nous voir sur le salon de SàT par exemple (sat@chat.jabberfr.fr), on peut trouver des tas de choses à faire qui sont plus ou moins accessible, et dans beaucoup de domaines différents (dev web, plugin, chiffrement, transfert de fichier, outil en ligne de commande, etc). Surtout que notre archi est modulaire, donc on peut bosser sur des parties isolées.

Si tu veux un truc qui profite à plusieurs projets à la fois, contribue sur une bibliothèque ou sur un serveur.

À vouloir être un standard et/ou un écosystème avant d'être un produit, XMPP tend à n'être qu'une solution pour développeurs, pas pour utilisateurs. Or, les développeurs libres sont très souvent d'abord des utilisateurs.

XMPP est un standard et n'a jamais été autre chose. C'est les logiciels qui l'utilisent qui sont ce que voient (ou pas dans certains cas) l'utilisateur. Il y a des gens qui ne font que du standard, et d'autres que du logiciels (sans même forcément implémenter le standard, des fois il suffit d'utiliser une bibliothèque).

soit je contribue à SàT, soit je contribue à Movim, soit je contribue à Jitsi

Ce sont des façons de faire différentes, c'est comme pour Kde et Gnome ou Vim et Emacs. Mais tu peux toujours aider les différents projets en même temps, comme dit plus haut.

Et si je veux implémenter MES idées avec MA techno, la marche est considérable, sans garantie de pouvoir échanger plus avec l'écosystème que du chat texte et de la présence.

Comme pour toute techno, il y a un ticket d'entrée, mais je pense qu'apprendre à lire des XEPs et repérer celles qui t'intéressent c'est pas hors de portée du tout. Et après ça s'adapte très très facilement à un cas particulier.

Là encore, la sauce n'a pas pris et WebSocket+WebRTC rendent les atouts d'XMPP-on-the-Web non-déterminants.

on n'est pas du tout au même niveau. XMPP peut très bien utiliser WebSocket et WebRTC (Movim le fait d'ailleurs).

Tu vois où je veux en venir?

Pas vraiment pour être honnête.

Enfin bref, vient sur les salons, j'aurais pu t'expliquer très facilement comment contribuer sans se taper des tonnes de docs à lire. En plus quelqu'un entrant dans le projet peut nous aider à documenter en fonction des problèmes qu'il rencontre…

Justement : Status Net, ça fait au moins 4 ou 5 ans que ça fait (faisait?) des trucs qu'XMPP a encore du mal à faire en matière de microbloggage. C'était tout sauf parfait (en termes de permissions notamment), mais ça juste-marchait.

Ils ont aussi un mode de fonctionnement différent: ils ont leur propre trucs, ils ne standardisent pas, et il y avait une boite derrière si je ne m'abuse, avec un certain nombre de dévs. Ils ont eu leur heure de gloire, mais j'ai l'impression que identi.ca a fait une belle erreur en passant à pump.io.

ça reste très laborieux. Pas pire qu'il y a 4-5 ans, mais on ne sent pas vraiment arriver le moment où on pourra le conseiller à tata Michue.

Le problème c'est toujours le même: on n'est pas beaucoup aidés. Donc on avance, mais lentement (enfin pas tant que ça vu le nombre de choses qu'on doit gérer). Movim c'est pareil, il y a 1 dev principal.

Jitsi, qui faisait partie des plus dynamiques des clients "génériques", ne bouge plus bien fort et sa dernière version vend vraiment du rêve : support d'IRC, support de Java 8, un nouveau codec et un splash screen (je caricature un peu, il y a beaucoup de boulot côté bugfix, mais ça n'est pas vraiment révélateur d'une phase d'expansion).

Jitsi ils étaient au Fosdem, y'avait une dizaine de personnes, c'est pas trop mal tout de même. Ils font des conférences à plusieurs avec vidéo, il n'y a pas beaucoup de logiciels qui permettent ça à ma connaissance.

Twitter est centralisé. Si tu veux le comparer, compare le à Elgg. C'est autrement plus simple de faire un truc centralisé (sans renier le travail sur ces logiciels).

XMPP tu peux le comparer à Diaspora ou Gnu Social (Status Net), et je crois qu'il n'a pas trop à rougir de ce côté. Surtout que son évolution dans un sens dépend de l'intérêt des développeurs, et l'intérêt pour le microblogage est plus récent que celui pour la visio par exemple.

Si j'étais très médisant, je dirai que SàT sera prêt quand Facebook sera en train de sombrer, remplacé par une autre techno plus à la mode.

Autant pour XMPP je ne trouve pas que ça soit un problème que ça mette du temps, parce que c'est un truc fait pour durer et pas être un effet de mode, autant pour SàT c'est différent: effectivement on met beaucoup plus de temps que ce qu'on avait prévu. C'est une chose courante dans l'informatique, et ce n'est pas parce qu'on glandouille mais parce qu'on a des problèmes à résoudre au fur et à mesure, et que quand on a fait un truc à la va vite, on essaye de bien le refaire plus tard.

C'est plus gênant parce qu'on a 2 problèmes: ceux qui viennent tester en s'attendant à avoir un truc fonctionnel, et notre propre motivation. Ceux qui viennent tester en général ça va quand on explique le pourquoi du comment (et que ça pourrait aller plus vite avec des coups de mains), pour notre propre motivation il y a des haut et des bas. En ce moment on fait des trucs chiants: construire une base solide pour le microblogage. Je pense que c'est la dernière ligne droite avant de construire les trucs vraiment sympa, et que si on fait ça suffisamment bien ça va être super.

Mais c'est difficile de bosser régulièrement, d'expliquer à famille et amis pourquoi on fait ça, de ne pas se décourager quand on passe une semaine sur un truc qu'on pensait faire en une aprem, de ne pas vouloir faire trop de bruit trop tôt par risque de déception, mais pas trop tard non plus parce qu'on va avoir besoin d'en vivre et d'avoir une motivation extérieure.

Bref oui, pour SàT c'est gênant que ça mette du temps (surtout maintenant), je pense qu'on est vraiment proche d'une vraie version grand public (pas la prochaine version mais la suivante), qu'on n'a pas du tout à rougir par rapport à ce qui se fait à côté, mais on a besoin de bouger rapidement pour notre propre motivation.

Excuse-moi mais quand on voit que pour avoir des fonctionnalités un peu différente de la base, il faut un client précis et un serveur précis, non on est plus compatible. Ça pourrait aussi bien être un protocole totalement différents.

je t'ai répondu plus haut: c'est faux. Il ne faut pas un client précis et un serveur précis, et pour le microblogage j'ai bon espoir que les 2 dernières XEPs donnent un gros coup d'accélérateur.

ce que l'on (pas toi je sais) appelle un client XMPP ne fait pas plus que ce que l'on trouvé il y a 10 ans et plus avec XMPP, MSN ou autre

C'est un choix des clients aussi. Gajim par exemple se concentre sur le messagerie et la visio, et j'avais discuté il y a un moment avec Asterix (le dév principal), il ne comptait pas faire de microblogage. Mais pour ce qu'il fait il le fait très bien, c'est une référence dans le domaine (je l'utilise en priorité pour tester nos implémentations par exemple). Et il fait tout de même messagerie chiffrée, messagerie de groupe, envoi de fichier et visio, c'est l'utilisation principale de la plupart des gens (j'avoue ne pas avoir trop testé la visio, je ne sais pas ce qu'elle donne).

Ça ne veux plus dire grand chose. Concevoir ces choses comme des couches est bien plus simple à appréhender (c'est ce qui est fait avec HTTP, SAOP, REST,…). Ça n'empêche en rien de faire les choses de manière ouverte et ça permet à chaque type d'utilisation d'avoir son propre cycle de vie indépendant des autres.

L'intérêt d'avoir ça au sein du même protocole, c'est que tu as déjà la gestion du compte unique, de la fédération, des extensions, etc. Pas besoin de mettre des couches de colle parfois sales entre les différents protocole. Et d'ailleurs la philosophie d'XMPP est de réutiliser l'existant quand il convient à la tache (Atom est utilisé pour le microblogage par exemple).

Le fait de devoir utiliser un fork précis de tel ou tel serveur pour pouvoir se servir de SàT et que coté client ça marche entre pas et mal avec pidgin et empathy par exemple c'est pas le propre de ce qu'on trouvait à l'époque d'MSN et des clients qui ne supportent que partiellement ce que fait le client officiel.

Tu te trompes. Certains clients ont choisi en effet de privilegier un fork de prosody, à savoir metronome, pour le microblogage; mais nous (SàT) avons décidé de faire notre propre service pubsub et avons proposé des XEP pour pouvoir les utiliser avec tous les serveurs. Je pense qu'une fois que les implémentations marcheront (c'est quasi certains qu'il y en aura au moins pour prosody et ejabberd, et ça ne m'étonnerait pas d'en voir dans OpenFire), il n'y aura aucun soucis pour utiliser n'importe quel serveur.

Mais ceci ne concerne que le microblogage, qui est en plein développement. Pour tout le reste, ça fonctionne à l'heure actuelle sans soucis avec n'importe quel serveur et n'importe quel client. Je communiquais jusqu'à la semaine dernière sans soucis avec gtalk par exemple, client et serveur différents des miens. Je ne sais pas où ça en est, ils ont annoncé la fermeture hier.

Oui il y a pleins de trucs qui marchent lors des démo, mais il faut avoir les conf qui vont bien, les logiciels en dernière version, etc.

Oui il faut souvent activer les trucs pour des raisons de sécurité/performance. Par exemple les privacy list (extension qui permet de dire qu'on ne veut pas recevoir tel type de message, pas envoyer par exemple notre présence à telle personne) sont désactivées par défaut dans prosody pour des raisons de performances. C'est pareil sur ton serveur: tu n'as pas un serveur HTTP, FTP, SMTP, etc activés d'entrée de jeu.

Aussi en ce qui concerne SàT particulièrement, on répète à chaque fois que ce n'est pas encore une version « grand public », parce qu'on se concentre sur le dév et qu'on n'a pas encore arrondi les angles. Quand on sortira la version « grand public », on passera par une phase de beta avec tests sur les différents serveurs, avec le plus de clients possibles, etc. C'est long, oui. Mais il faut rappeler qu'on n'est que 2, qu'on a décidé de travailler sans actionnariat ou levée de fonds, qu'on refuse d'utiliser FB et Zozio pour communiquer, et qu'on doigt bosser sur plusieurs fronts en même temps (les standards, le service pubsub, parfois les serveurs, les différents frontaux, les rencontres et évènements, le site web, les trolls sur DLFP, etc).

Pour moi au contraire, LE reproche qu'on devrait faire à XMPP, c'est la lenteur exaspérante de son procédé de standardisation, qui va toujours moins vite que le reste du monde (y'a qu'à voir la voix/vidéo, ou d'actualité, le microblogage).

Oui ça c'est un problème, et on a besoin de jouer des coudes pour faire avancer où on veut: PubSub on s'est regroupé pour y arriver, mais clairement on avance maintenant.

Y'a vraiment des gens de tous les domaines (on ne voit déjà pas pareil quand on travail sur un serveur ou sur un client), certains qui font de la recherche, certains qui font de l'internet des objets (donc je ne suis pas fan du tout), certains du pubsub etc. Du coup il y a un gros niveau technique (y'a des sujets où on est facilement largués et on doit se mettre à niveau si on veut suivre).

Par exemple j'avais expliqué dans mon dernier journal que ma proposition de XEP (protoXEP) pour générer des permissions privilégiées avait été refusée parce que ça n'était pas l'état de l'art. On m'a parlé de contrôle basée sur les attributs (Attribute Based Access Control, ABAC) que je ne connaissais pas. J'ai dû me renseigner et lire de la doc technique pour me mettre à niveau et pouvoir discuter correctement, j'ai pu mieux comprendre le refus (même si je ne suis pas forcément d'accord, et d'ailleurs la discussion qui a suivi a été enflammée). Maintenant j'envisage de faire une XEP qui permet de faire de contrôle d'accès par attribut en XMPP, qui pourrait être utilisée comme système de contrôle générique pour les futures extensions. Ça a été beaucoup plus long au final que si j'avais fait le protocole mo même et dit « on fait comme ça point », mais il est possible qu'il en sorte (ou pas) une meilleure solution technique.

Ouai mais leur implémentation sont pourris (pas de fédération par exemple). Donc oui, ils l'utilisent mais on est loin d'un vrai succès pour XMPP.

Gtalk est fédéré (enfin était, ils devaient couper hier je ne sais pas si ça a été fait réellement), c'est FB qui ne l'est pas (de ce que j'ai entendu, ça serait en fait une surcouche qui fait une passerelle XMPP - sans fédération -, en interne ça serait un truc maison).

Là où Gtalk avait des problèmes, c'était pour jingle: comme ils ont fait la première implémentation ils ont continué à l'utiliser même après la standardisation (la version standard a mis du temps à sortir, et a évolué pas mal a priori - enfin je n'ai pas encore touché à jingle, donc je ne vais pas trop m'avancer sur ce sujet que je connais mal -). Ensuite ils sont passé à la version standard il me semble.

Ça montre bien l'un des gros problèmes de XMPP : le protocole pars dans tous les sens et multiplie les XEP et ça produit un tas d'incompatibilités.

Effectivement le protocole part dans tous les sens et multiplie les XEP, mais c'est une force et non un problème, et au contraire ça rend les choses compatibles. C'est un protocole de communication, la communication ça sert dans à peu près tous les domaines; une fois qu'on a une base on a 2 options:

• chacun utilise la base et fait ça sauce dessus pour ses besoins spécifiques, et c'est la fête (un peu ce qui s'est passé avec HTTP/HTML/Javascript, et la situation s'améliore lentement avec ça)

• ou alors quand on a besoin d'un truc dans un domaine, on cherche une solution qui est équilibrée entre facilité d'implémentation et généricité, et on fait une extension au standard en discutant avec les autres pour voir si ça leur convient, c'est ce que fait XMPP avec les XEP.

L'incompatibilité c'est dans le premier cas qu'on la trouve.

J'ai du mal à croire que "se farcir toutes les XEP" soit plus long et compliqué que réécrire tout ce dont on a besoin de 0. Surtout qu'on parle ici d'un protocole qui pourrait utilisé des briques éprouvées plutôt que des nouvelles. Un bogue dans un protocole, ça me semble autrement plus chiant que dans une implémentation particulière.
Encore une fois: XMPP a ici l'avantage de son ancienneté.

Les extensions et leur nombre est une force. Il ne faut pas tout lire quand on veut implémenter quelque chose, les extensions sont utiles pour différents domaines et leur nom suffit en général à identifier ce dont on a besoin, + quelques unes qui sont indispensables comme discovery (qui permet de savoir quelles fonctionnalités sont disponibles, ou si on parle à un serveur, un client, un service MUC, un transport, etc) ou data forms (qui permet d'échanger des données de manière standardisées). Ces 2 dernières extensions sont simples à comprendre, et générique elle sont réutilisées partout. Ce qui fait qu'une fois implémentées, il suffit de réutiliser le code pour adapter à un cas particulier (par exemple discovery sert à savoir quelles commandes ad-hoc sont disponibles, ou plus concrètement ça me permet de savoir ce que je peux faire pour administrer mon serveur prosody depuis mon client XMPP).

Quand 2 extensions font la même chose, la meilleure est gardée et l'autre est dépréciée.

Bref, quelqu'un qui utilise XMPP pour commander un robot ne va pas utiliser la même chose que quelqu'un qui fait un logiciel de microblogage, ou que quelqu'un qui s'en sert pour faire du transfert de fichiers. L'intérêt d'avoir tous ces domaines dans des XEPs et qu'on parle la même langue, et du coup on est compatible, on a un seul compte, on peut changer de logiciel, etc. Comme je l'ai dit plus bas, on retrouve la philosophie Unix: chaque XEP fait 1 chose, et la fait bien (et du coup il en faut beaucoup).

Beaucoup d'entreprises utilises XMPP avec des trucs à eux qu'ils ne documentent pas, c'est possible aussi. Ils ont une base solides avec de nombreuses implémentation, et on juste à adapter l'existant à ce qu'il leur faut.

De même, "se farcir toutes les couches basses de XMPP" est-il vraiment un chemin de plus grande résistance que d'inventer et implémenter de nouvelles couches basses?

« les couches basses » c'est les RFC (6120, 6121, 6122), et ça n'est pas très compliqué à comprendre. En plus il ne doit pas y avoir beaucoup de langages où il n'existe pas de bibliothèque qui implémente ça.

Le fait de préciser «somme toute» montre bien qu'en fait, ce n'est pas vraiment le succès espéré. Ça reste une niche.

Une niche ? Cherche un peu des trucs comme ejabberd ou sametime pour voir si c'est une niche.

Ça fait à peu près 15 ans que XMPP (ou son ancêtre Jabber) existe. S'il reste des choses à faire, c'est qu'à un moment donné, il y a quelque chose qui ne tourne pas rond.

Je suppose donc que quelque chose ne tourne pas rond avec HTML, Javascript, Python, C, C++, Java, Perl, Linux, LibreOffice, Gimp, Apache… bon j'arrête là je crois.

Est-on condamné à devoir utiliser XMPP parce que c'est libre ou alors est-ce qu'on peut inventer d'autres protocoles de 0 et qui seront tout aussi libre et qui ont des chances d'avoir plus de succès que XMPP ? Les défauts de XMPP sont connus et rien ne change pour les corriger, au contraire, on dirait presque des features maintenant. J'aurais été à leur place, j'aurais fait exactement pareil.

Personne n'interdit qui que ce soit à faire autre chose. Il y a certes des défauts dans XMPP, on y travaille, mais ceux que je vois ne sont jamais cités.

Imaginons qu'ils aient voulu implémenter leur protocole par dessus XMPP. Déjà il faut se farcir toutes les XEP pour voir s'il y a des choses qu'on peut réutiliser.

Tu trouves ça mal de réutiliser des choses ? Tu n'utilises jamais une bibliothèque, un protocole standard, ou… un logiciel libre ?

Ensuite, il faut écrire sa propre XEP.

Oui enfin ça c'est quand on veut faire un truc générique qu'il n'est pas encore possible de faire, c'est quand même assez rare (j'ai écrit ma première XEP cette année alors que je bosse avec XMPP depuis plus de 7 ans).

Bon aller je vais me coucher, je reviendrai troller demain :)

On était voisins au Fosdem (« lounge » XMPP et Matrix), on a pu un peu discuter, et j'ai assisté à la conf. Je voulais en parler dans un résumé du Fosdem que j'avais commencé à écrire, mais au final je n'ai pas eu le temps et je suis passé à autre chose (et puis bon faut se remettre du rigodon de Dunkerque).

Le projet m'a eu l'air intéressant, pas nécessairement impressionnant (je n'ai rien vu de vraiment nouveau), mais prometteur. Je vais sûrement suivre ça. Malgré la jeunesse du truc, ils ont réussi à faire déjà pas mal de choses, mais il faut aussi relativiser: les gens ont applaudi pour la visio avec WebRTC, alors qu'à mon sens c'est plutôt les mozilla and co qu'il faut applaudir pour ça. J'ai aussi eu l'impression qu'il y avait un rejet de XMPP que je trouve dommage (comment peut on critiquer le côté extensible ? C'est justement ce qui rend le protocole est génial). Je renvoi au commentaire de Jehan qui démontait pas mal d'idées reçues.

Donc à mon sens Matrix est un projet prometteur à surveiller.

Maintenant revenons en à XMPP, vu que nous avons aussi été au summit qui précédait le Fosdem. Je vois, comme souvent, une méconnaissance ou mauvaise compréhension de XMPP dans les commentaires ici. XMPP est un protocol très simple qui se base sur 3 types de données (les stanzas):

• <message/> pour les requêtes de type j'envoi est j'oublie

• <iq/> pour les requête de type question/réponse (avec réponse obligatoire)

• <presence/> pour les données broadcastées

une fois qu'on sait ça, on connait l'essentiel. Les extensions, c'est plus ou moins la philosophie Unix: chaque extension gère une chose, et la gère bien (enfin disons que c'est discuté jusqu'à arriver à la meilleure solution possible). et dans toutes les extensions, il y en a très peu qui sont vraiment finales, beaucoup sont expérimentales, soit parfois très éloignées de la version idéale (c'est pour ça que ça discute beaucoup, c'est une des raisons qui rend les nombreux clients avec des façons de faire différentes utiles, c'est pour ça que c'est bien qu'on voit des gens de milieux techniques différents).

XMPP peut parfaitement être distribué (avec un client=1 serveur) et on est beaucoup à envisager ça à terme, c'est déjà possible en réseau local. Après ça n'est pas forcément la solution idéale pour tous les cas d'utilisation, et différents serveurs intermédiaires ça a ses avantages (pour encore faire une analogie: il ne faut pas réinventer l'opposition microkernel et kernel monolithique).

Maintenant quelques sujets qui on été abordés au summit:

• le chiffrement de bout en bout, mais c'est un vieux sujet dans XMPP, qui a du mal à trouver une solution qui marche bien. Pour le moment il est question de documenter l'utilisation actuelle d'OTR, d'éventuellement faire une XEP qui adapte OTR à XMPP. Il est question de faire un prochain summit dont c'est le sujet principale, avec hackathon dans la foulée.

• des discussions sur un MUC 2 (Multi-Users Chat, les conversations à plusieurs type IRC). Il semble qu'on arrive à un MUC basé sur les mécanismes PubSub, avec une fédération facilitée.

• On parlé aussi d'un MUC sans présence, une équipe fait des expérimentation avec ça. L'intérêt est surtout pour les téléphones où on se connecte/déconnecte souvent. Enfin pour moi on réinvente surtout PubSub, je ne suis pas convaincu de l'intérêt

• Nous avançons sur PubSub, comme je l'avais expliqué dans un précédent journal. D'ailleurs la deuxième XEP dont je parlais dans ce journal est passée juste avant le summit, et en Belgique on a pu avoir pas mal de contacts pour nous aider, l'année 2015 devrait être particulièrement intéressante. Au passage edhelas nous a fait une démo de l'appli Movim pour Android, c'est très sympa.

Bref, ça bouge. XMPP est très utilisé, et ce n'est parce que Gtalk va (est ?) fermer qu'il est mort. Ejabberd arrive à en vivre, Jitsi arrive à en vivre, Mongoose IM arrive à en vivre, Buddycloud arrive à en vivre, Prosody arrive à en vivre, OpenFire arrive à en vivre, etc. Sans parler de toutes les applications de messagerie à la mode qui sont 9 fois sur 10 du XMPP avec des extensions proprio.

Bon je ne vais pas faire un roman parce que je vais me coucher, mais je trouve très bien qu'il y ait des expérience sur de nouveaux protocole, et de nouvelles idées. Ceci dit, je doute fort de voir quelque chose arriver au niveau de XMPP tant en terme de possibilités que de clients/serveurs avant longtemps.

Salut,

l'assoce est un peu difficile à joindre: j'ai envoyé un message à l'adresse de contact sans réponse, sur IRC il y a très peu d'activité, et on m'a plus ou moins répondu via Lille Makers. Le site n'est pas du tout à jour non plus (il y a bien des messages relativement récents sur le blog de la page principale, mais le reste date plutôt des environs 2008).

Bref, c'est super si ça reprend vraiment, faut voir sur le moyen/long terme.

Je ne pense pas pouvoir venir à l'A.G. (je ne suis pas à côté), mais j'essaierai de venir à une prochaine rencontre.

Bref c'est exportable avec un outil libre et maintenir une sauvegarde à jour est trivial

Bon c'est déjà ça

Quelle forge libre permet aussi facilement de libérer les données et d'intéropérabilité ?

J'héberge moi même mes serveurs de travail, donc je n'ai pas ce soucis, les données se sauvegardent en même temps que le reste. Je suppose que les outils libres intégrés ont un système d'export, non ?

Ce qu'il manque c'est les rapports de bug. Techniquement ça pourrait aussi être géré via un plugin (j'avais vu passer ça il y a quelques mois).

Si je comprends bien, les rapports de bogues ne sont pas exportables ? C'est quand même majeur non ?

Bref github est de ce que j'en sais la meilleure forge (libre ou non) pour ce qui est de la pérennité de tes données.

Je n'utilise pas donc difficile de juger. On n'utilise pas une forge tout intégré, mais les outils de référence dans chaque domaine (mediawiki pour le wiki, bugzilla pour les rapports de bogues, etc). L'inconvénient majeur par rapport à une solution intégrée, c'est qu'on n'a pas un compte unique (encore que ça pourrait se faire assez facilement, je crois même que des distros comme Yunohost gèrent ça directement). Dans notre cas ça n'est pas un problème, pas assez de monde dessus pour que ça le soit et qu'on s'embête avec ça. Si ça le devient, on avisera le moment venu.

Genre le nombre de commits que tu fais ? Ce n'est pas publique dans les projets open source dont le développement est ouvert ?

Les projets que je télécharge (si j'ai envie d'étudier crack_dernier_jeu_a_la_mode) auxquels je contribue (si j'ai envie de contribuer sur outil_utilisé_par_un_mouvement_politique par exemple), les messages que j'échange, le contenu que j'échange, les contacts que j'ai, ma fréquence de travail, mes heures de connexion, etc. Une partie de ces données est accessible publiquement (on peut étudier la qualité de mon code chez moi par exemple), mais c'est beaucoup plus difficile de recouper quand c'est éparpillé, et il y a des données qui ne sont pas accessibles à tout le monde.

Il y beaucoup plus d'informations qu'on le croit quand on utilise un service, alors si tout le monde utilise le même (et qu'il est centralisé), ça pose un gros problème.

Je n'aime pas non plus d'avoir les outils et formats imposés (j'aime bien mercurial, je n'ai rien contre markdown - quoi que ça manque de standard - mais ça aurait pu être un format que je n'aime pas du tout).

Si un jour ça tombe ce sera comme quand kernel.org est tombé dans les heures qui suivront les gens iront sur bitbucket, google-code, assembla, redmine, etc et récupéreront tout sauf leur ticket malheureusement.

Il y a quand même une sacré différence entre 1 seul projet majeur, et des milliers voire plus de projets dont beaucoup portés par peu de personnes voire 1 seule.

Enfin bref, j'ai aussi un problème de cohérence: comment on peut se dire libriste (je ne dis pas que tous ceux sur gittruc se disent libriste), et utiliser un service proprio centralisé derrière, alors qu'il y a des alternatives libres ? Certains disent vouloir un vrai internet (minitel toussa toussa), et mettent tous leurs projets sur gittruc. De la même manière, comment on peut-on dire défendre la vie privée et utiliser FB ? Et oui j'ai un bios proprio sur ma machine.

• Github possède une API REST, donc tout est consultable ;

Il n'y a pas de lien entre avoir une API et que tout soit consultable. N'est consultable (du moins par les moyens officiels) que ce qu'ils exposent. Peut-être que toutes les données sont accessibles, il faut voir dans quelles conditions. D'ailleurs est-ce que les licences des rapports de bogues, wiki etc sont libres ? Au choix du projet ?

• les web-hooks permettent d'intercepter toutes actions sur un dépôt, donc tout est exportable ;

Pareil, c'est pas parce que tu peux déclencher un événement que tu peux tout exporter. L'historique est accessible ? On peut tout récupérer facilement dans un format facile à exploiter (par exemple XML ou au pire CSV) ? Pas besoin de se taper l'API pour chaque entrée ?

Je n'en sais rien je n'utilise pas github, ce sont de vraies questions.

• un wiki est un dépôt git, donc exportable aussi.

Le format est documenté ? Standard ?

Si tout est effectivement facilement accessible, c'est déjà une chose. Mais ça reste proprio, centralisé et beaucoup trop massif. Sans compter l'utilisation pour les employeurs potentiels, voire les statistiques possiblement faites sur les utilisateurs (j'en sais rien je suppute, mais comme on n'a pas la maîtrise du serveur, impossible de vérifier).

Et si un jour ça tombe, on perd l'accès d'un coup à un paquet de projets (qui n'auront pas disparu, vu que c'est du git les dépôts sont un peu partout, mais ça sera quand même coton à récupérer).

Très bon tuto, merci. Il y a un </pre> qui traine dans l'exemple iptable (c'est pour trouver le bonheur ?).

edit: et aussi on ne devrait plus utiliser le terme Jabber, il faudrait remplacer par XMPP

Je ne suis pas spécialiste, mais c'est nettement plus agréable de dessiner (surtout à la tablette !) sur du matriciel que sur du vectoriel.

Essaye MyPaint, c'est excellent: tu peux choisir le type de feutre/crayon/pinceau, si t'es à la tablette la pression est prise en compte (c'est le cas aussi en vectoriel, mais je pense que le résultat est moins fin), tu as une sensation proche du dessin papier.

Sur Inkscape tu peux modifier après coup et faire plein de choses sympas (cf. les conférences de Gee sur le sujet aux RMLL), mais la sensation est bien plus éloignée du dessins papier, et je pense que c'est beaucoup plus lourd de simuler des outils réels (par exemple une tache d'encre en matriciel ne sera qu'un amas de pixels, plus ou moins aléatoires et foncés, en vectoriel ça sera une formule complexe qui garde toutes les composantes).

Pour résumer: le matriciel se rapproche probablement plus du dessin papier. Regarde les vidéos de démo de MyPaint de David Revoy (cité dans la dépêche d'ailleurs), c'est très impressionnant, et ça m'étonnerait qu'on puisse faire la même chose avec Inkscape.

Pour le moment on n'a pas assez de contributions extérieures pour avoir de gros problèmes de revue de code, et on se fait les commentaires directement en discutant sur XMPP. On a un Mercurial hébergé chez nous (et un Bugzilla, un Mediawiki), et on est très content avec.

Dans l'idéal j'aimerais faire un système de revue de code basé sur XMPP, on a pratiquement tout ce qu'il faut, mais c'est du boulot et on a d'autres priorités pour le moment (mais vu que ça nous servirait pour le développement, ça peut valoir le coup de passer du temps dessus).

Bon nous on a été un peu déçus sur ce qu'on a eu (pas de devroom XMPP, ça fait 2 ans de suite :( ), et les 2 « lightning talks » que j'ai proposé ont été refusées :( :(

Par contre il y aura l'habituel « lounge » XMPP, et si vous voulez venir voir une démo et/ou discuter de Salut à Toi ou autre (il y aura aussi Edhelas de Movim, et plein de beau monde de la communauté XMPP), nous devrions y être assez souvent (pas tout le temps parce qu'on vient voir des confs et boire des bières aussi !). On sera aussi à l'apéro Python le samedi soir.

La centralisation aussi. Github serait libre que je n'irais probablement toujours pas, car je n'ai pas envie de créer un compte là bas. Aussi il faut voir si toutes les données sont faciles à récupérer (donc ça comprend rapports de bogues, wiki, blogs, etc), est-ce que c'est le cas ? Accessoirement j'aime bien avoir la main sur ce que j'utilise pour pouvoir adapter au besoin, mais ça je comprends qu'on n'ait pas envie de tout administrer soi-même.

Ça ne peut pas se régler à coups de LD_PRELOAD ça ?