Dans ce cas précis, la complexité sera dans un composant (ou entité) dédié, pas dans le client, donc ça ne perturbe pas trop cette philosophie.
Mais de manière générale, les clients gèrent de plus en plus de choses, et la complexité augmente: il est possible d'avoir du pubsub sur le client lui même si on veut, et pour l'audio vidéo c'est clairement le client qui gère le plus de choses.
Après c'est des possibilités, des fonctionnalités à implémenter ou non, un client de base qui ne ferait que de la messagerie peut toujours s'implémenter de façon très simple.
Effectivement, les XEPs ne sont pas spécifiques aux composants (même si ça leur est principalement destiné dans un premier temps)
Il y a bien une méthode « traditionnelle » historique (la XEP-0114) pour connecter des composant: c'est une sorte de client simplifié, et dans le conf du serveur on met un jid à associer et un mot de passe, et voilà.
Cette méthode est simple et peu moderne, mais a le mérite d'être répandue et fonctionnelle. La XEP-0225 est plus moderne (elle permet d'utiliser TLS par exemple), mais je ne pense pas que son adoption est aussi systématique dans les serveurs. Enfin je ne me suis jamais trop penché dessus, vu que pour l'instant la XEP-0114 nous convient. Mais je pense qu'à terme, la XEP-0114 va être dépréciée au profit de la XEP-0225 ou une plus récente, mais ça prend du temps (parce que ça marche en l'état, c'est un peu le même problème avec l'adoption de pubsub pour les signets (bookmarks)).
edit: pour être bien clair, les nouvelles XEPs n'ajoutent rien pour la connexion d'un composant (ce qui existait déjà comme tu l'as dit); elles leurs permettent d'avoir un accès privilégié aux serveurs de manière générique, et de gérer des fonctionnalités qui ne pouvaient pas l'être en dehors du serveur avant.
la spécification censée faire ce dont vous avez besoin est longue, complexe, imprécise et lourde à implémenter, donc inutilisable
j'ai dit longue et complexe (encore que le complexe résulte surtout de la longueur, le principe est simple), pas imprécise et encore moins inutilisable (on l'utilise tous les jours !).
vous avez donc créé deux spécifications plus simples, plus courtes et plus précises donc plus facilement implémentables en espérant que d'autres vous suivront.
On a écrit 2 spécifications (relativement faciles à implémenter) qui permettent de développer à l'extérieur des choses qui étaient réservées au serveur, autrement dit on décentralise le code.
ah au cas où c'est pas clair aussi, même si on n'a pas encore lancé la campagne, vous pouvez déjà adhérer si vous voulez soutenir le projet, même pour 0 € :)
En effet, contrairement à ce qu'on pense souvent, il est possible d'être salarié et membre du bureau en même temps et c'est ce qu'on souhaite faire.
Dans ce cas la gestion est intéressée et il n'y aucun avantage fiscal (encore une fois, c'est tout à fait normal). Et oui on sera le plus transparent possible, on a déjà essayé d'expliquer les choses clairement sur le site (n'hésitez pas à nous dire si ça n'est pas assez clair), et il suffit de nous rejoindre sur le salon XMPP de SàT (sat@chat.jabberfr.org) pour poser des questions.
Aussi on n'a pas de président/secrétaire/trésorier vu qu'on est en autogestion et donc sans hiérarchie. Ça surprend souvent les gens y compris dans l'administration, mais c'est tout à fait possible.
Dans l'idéal tout serait implémenté par tous les serveurs oui.
Mais en pratique les implémentations sont soit inexistantes, soit incomplètes, soit ont des problèmes de performances.
Alors pourquoi c'est comme ça ? La XEP-0060 et une XEP longue et complexe (c'est une des plus longues de XMPP), et de nombreuses choses sont optionnelles. Les implémentations sont souvent incomplètes pour une ou plusieurs de ces raisons:
beaucoup de serveurs et clients se concentrent plutôt sur la messagerie instantanée, même si je pense que c'est en train de changer
comme peu de clients utilisent pubsub de manière intensive, il y a peu de demandes pour améliorer les implémentations côté serveurs
beaucoup de choses optionnelles, donc même si on a une implémentation, on n'a pas forcément ce que l'ont souhaite
il y a des choses comme les signets (bookmarks ou XEP-0048) qui au départ n'utilisaient pas pubsub - qui n'existait pas - et qui ont ensuite été mises à jour pour utiliser pubsub. Comme la première implémentation marche, beaucoup ne voient pas de raison de changer.
et surtout c'est un gros boulot, un projet à part entière, il faut les ressources pour implémenter pubsub + le boulot déjà existant sur le serveur.
Bref à mon sens c'est beaucoup plus logique d'avoir ça comme composant extérieur complet, que comme un parent pauvre du serveur. Et si on veut améliorer l'implémentation d'un serveur ça peut aller, mais tous les serveurs avec les dizaines de langages et d'architectures utilisés, c'est plus compliqué.
D'autre part, nous bougeons beaucoup sur PubSub, et il peut y avoir de nouvelles XEPs à implémenter, qui mettront du temps à arriver dans les serveurs: avec la maîtrise du composant, on peut faire une implémentation immédiatement (et pour tous les serveurs !), la chaîne de développement est beaucoup plus rapide.
Dans notre cas particulier, nous avons une extension non standard (pour le moment) qui permet d'envoyer un message à un groupe uniquement: vu qu'il n'y a pas de XEP associée, aucune chance de voir ça dans un serveur. Là on peut tester et améliorer avant de proposer une XEP.
Enfin oui ces 2 XEPs sont beaucoup plus faciles à implémenter (il m'a fallu quelques jours pour Prosody alors que ce sont mes premiers modules pour ce serveur), regarde leur taille et compare à la XEP-0060 pour comprendre, et ça peut servir dans d'autres cas qu'un composant PEP/PubSub. D'autre part tout ce qui est nécessaire à faire un service PEP est obligatoire dans ces XEPs, alors que tout ce dont on a besoin dans PubSub ne l'est pas forcément. Donc si elles sont implémentées, on est sûr d'avoir ce qu'il faut.
Oui c'est un peu ça. Vous pouvez lire les statuts et le règlement intérieur pour mieux comprendre: les membres du bureau (un bureau collégial qui prend les décisions au consensus) sont les membres actifs, et ceux qui seront (on l'espère) salariés: si on a suffisamment de sous à terme et qu'on veut salarier quelqu'un d'autre, il sera membre du bureau.
Les adhérents n'ont aucun obligation de participation, même si on a une liste de diffusion pour les adhérents et qu'on aimerait les rencontrer régulièrement.
Nous avons choisi la forme associative pour plusieurs raisons: déjà c'est très facile à créer, d'autre part c'est assez souple pour s'organiser comme on le souhaite, ensuite le but non lucratif même s'il ne protège pas de tout évite au moins l'actionnariat (ce que nous voulions) et d'accumuler l'argent n'importe comment. Il y a aussi d'autres avantages: le don à une entreprise n'est pas possible ou très difficile alors que possible pour une association. Ici l'adhésion est une forme de soutien tout à fait légal (mais nous paieront des impôts dessus une fois salariés, ce qui est tout à fait normal).
Autre chose: il est très difficile de transférer le capital d'une association sauf vers une coopérative. Or nous envisageons la coopérative à terme.
Bref, vois l'association comme une façon de « tester » l'activité, et comme un cadre légal, et l'adhésion comme un moyen de nous soutenir.
Ah aussi je précise qu'on aimerait un don régulier, mais annuel: on a une fourchette de dons qui va de 0 à 100, mais on espère une moyenne de 10€/adhérent/an, autrement dit même pas un café par mois ! Nous ferons un rappel à chaque adhérent tous les ans (pas du spam, un rappel gentil :)), sans aucune obligation de redonner ou de donner le même montant (on peut donner 10 € un an et rester adhérent pour 0 € l'année suivante, ou ne plus être adhérent du tout).
Voilà, j'espère que c'est plus clair. Nous envisageons le financement participatif pour nous lancer également…
Oui c'est assez sympa de se dire qu'on va pouvoir discuter ensemble et faire un réseau plus large en dehors de la messagerie instantanée où c'était déjà le cas.
Je pense que d'autres projets vont suivre: du côté de Poezio (très bon client XMPP console pour ceux qui lisent), ils ont commencé à parler d'une implémentation du microblogage également, j'aimerais beaucoup voir ça dans Gajim aussi, mais la dernière fois que j'en ai parlé au dév principal (il y a plusieurs années tout de même), il n'en était pas question, ils voulaient se concentrer sur la messagerie/vidéo conf (ce qui est un choix tout à fait compréhensible).
Pour ceux qui lisent ce commentaire, il y a d'autres point sur lesquels on avance, notamment avec edhelas (et quelques autres personnes) on est en train d'essayer de revoir les signets (bookmarks).
Le statut varie suivant les pays mais en gros ça t'assure seulement que le "conseil d'administration" n'est pas rémunéré pour les tâches qui découlent de ce rôle (mis éventuellement dédommagé). Tu n'as pas d'actionnaires ou truc du genre. Les dons faits aux associations ouvrent souvent droit à des avantages fiscaux. Les clients des associations s'appellent des adhérents et doivent payer une cotisation.
C'est faux ça. Tu peux très bien te rémunérer en étant au conseil d'administration, c'est d'ailleurs ce qu'on espère faire avec « Salut à Toi ». Tu n'as effectivement pas d'actionnariat dans une association type loi 1901 et tu ne peux pas accumuler de l'argent dans le vide, il faut des projets. Bref tu ne peux pas faire n'importe quoi, et si l'association est dissoute, tu ne peux pas filer l'argent qu'elle a à n'importe qui et n'importe comment.
Les dons faits aux associations ouvrent souvent droit à des avantages fiscaux.
Dans des cas très particuliers (comme association d'intérêt général). Dans notre cas en se salariant en étant au conseil d'administration, nous aurons une « gestion intéressée » et serons soumis aux impôts divers au même titre qu'une entreprise classique, ce qui me semble tout à fait normal.
Il y a une loi qui est passée il y a un an environ sur l'économie sociale et solidaire, concernant surtout les coopératives il me semble, mais je n'ai pas encore regardé ça en détails.
Les clients des associations s'appellent des adhérents et doivent payer une cotisation.
Le paiement d'une cotisation n'est absolument pas obligatoire, ça dépend des statuts. Chez nous il ne l'est pas par exemple.
Maintenant tout le reste ben… Le conseil d'administration peut toujours nommer un directeur et lui verser la totalité des rentrées d'argent de l'association sous forme de salaire ou tout reverser à une société cotée en bourse en échange d'un bout de papier sur lequel est écrit "facture".
Je doute très fort que ce que tu dis soit possible en l'état. Après je ne suis pas spécialiste non plus, et il y a sûrement moyen de contourner l'esprit d'origine. Mais il y a un encadrement légal ça c'est sûr. Je suppose que beaucoup de choses se font pas manque de contrôles aussi…
Franchement le statut d'une structure ne présage en rien de ses activités.
Ça c'est plutôt vrai, ça ne donne qu'un cadre légal. L'entreprise ou assimilé est ce qu'on en fait derrière, et dans tous les cas il y a probablement moyen de contourner et détourner des choses tant qu'on n'est pas pris…
Ma boite est constitué d'associations, de SARL, de SCI etc… Et les associations n'ont pas un but plus humain que les SARL, juste un statut plus avantageux pour l'activité. Je suis salarié d'une association et on attend de moi que je fasse cracher nos "adhérents".
Statut différent, pas nécessairement plus ou moins avantageux. Le but non lucratif a un sens légal et ce n'est pas rien. Mais une SARL peux être bien plus éthique qu'une association selon la façon dont elle est dirigée.
Après but non lucratif ça ne veut pas dire ne pas se salarier, ça veut dire qu'amasser de l'argent n'est pas le but de l'entité.
Merci pour avoir relayé cet article intéressant et politique, qui sort un peu des dépêches AFP à peine réécrites habituelles.
On voit ici l'un des effets pervers et dangereux du développement d'internet, ou plutôt de son utilisation par certaines entreprises (parce qu'au final ce n'est pas internet le problème, mais bien l'utilisation par A. - et beaucoup d'autres ! - pour casser le droit du travail et profiter de la misère). Alors que d'un autre côté il y a des exemples superbes comme Wikipédia (qui a ses défauts, mais est globalement une réussite énorme).
Raison de plus pour boycotter cette multinationale et celles qui ont un comportement similaire.
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.
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.
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.
[^] # Re: serveurs et clients
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
Dans ce cas précis, la complexité sera dans un composant (ou entité) dédié, pas dans le client, donc ça ne perturbe pas trop cette philosophie.
Mais de manière générale, les clients gèrent de plus en plus de choses, et la complexité augmente: il est possible d'avoir du pubsub sur le client lui même si on veut, et pour l'audio vidéo c'est clairement le client qui gère le plus de choses.
Après c'est des possibilités, des fonctionnalités à implémenter ou non, un client de base qui ne ferait que de la messagerie peut toujours s'implémenter de façon très simple.
[^] # Re: Fusion avec XEP-0114
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3. Dernière modification le 27 mai 2015 à 17:45.
Effectivement, les XEPs ne sont pas spécifiques aux composants (même si ça leur est principalement destiné dans un premier temps)
Il y a bien une méthode « traditionnelle » historique (la XEP-0114) pour connecter des composant: c'est une sorte de client simplifié, et dans le conf du serveur on met un jid à associer et un mot de passe, et voilà.
Cette méthode est simple et peu moderne, mais a le mérite d'être répandue et fonctionnelle. La XEP-0225 est plus moderne (elle permet d'utiliser TLS par exemple), mais je ne pense pas que son adoption est aussi systématique dans les serveurs. Enfin je ne me suis jamais trop penché dessus, vu que pour l'instant la XEP-0114 nous convient. Mais je pense qu'à terme, la XEP-0114 va être dépréciée au profit de la XEP-0225 ou une plus récente, mais ça prend du temps (parce que ça marche en l'état, c'est un peu le même problème avec l'adoption de pubsub pour les signets (bookmarks)).
edit: pour être bien clair, les nouvelles XEPs n'ajoutent rien pour la connexion d'un composant (ce qui existait déjà comme tu l'as dit); elles leurs permettent d'avoir un accès privilégié aux serveurs de manière générique, et de gérer des fonctionnalités qui ne pouvaient pas l'être en dehors du serveur avant.
[^] # Re: Déplacer le problème ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4.
j'ai dit longue et complexe (encore que le complexe résulte surtout de la longueur, le principe est simple), pas imprécise et encore moins inutilisable (on l'utilise tous les jours !).
On a écrit 2 spécifications (relativement faciles à implémenter) qui permettent de développer à l'extérieur des choses qui étaient réservées au serveur, autrement dit on décentralise le code.
[^] # Re: Adhésions ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
ah au cas où c'est pas clair aussi, même si on n'a pas encore lancé la campagne, vous pouvez déjà adhérer si vous voulez soutenir le projet, même pour 0 € :)
http://salut-a-toi.org/adhesion.html
[^] # Re: Adhésions ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4.
En effet, contrairement à ce qu'on pense souvent, il est possible d'être salarié et membre du bureau en même temps et c'est ce qu'on souhaite faire.
Dans ce cas la gestion est intéressée et il n'y aucun avantage fiscal (encore une fois, c'est tout à fait normal). Et oui on sera le plus transparent possible, on a déjà essayé d'expliquer les choses clairement sur le site (n'hésitez pas à nous dire si ça n'est pas assez clair), et il suffit de nous rejoindre sur le salon XMPP de SàT (sat@chat.jabberfr.org) pour poser des questions.
Aussi on n'a pas de président/secrétaire/trésorier vu qu'on est en autogestion et donc sans hiérarchie. Ça surprend souvent les gens y compris dans l'administration, mais c'est tout à fait possible.
[^] # Re: Déplacer le problème ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 10. Dernière modification le 27 mai 2015 à 11:30.
Dans l'idéal tout serait implémenté par tous les serveurs oui.
Mais en pratique les implémentations sont soit inexistantes, soit incomplètes, soit ont des problèmes de performances.
Alors pourquoi c'est comme ça ? La XEP-0060 et une XEP longue et complexe (c'est une des plus longues de XMPP), et de nombreuses choses sont optionnelles. Les implémentations sont souvent incomplètes pour une ou plusieurs de ces raisons:
beaucoup de serveurs et clients se concentrent plutôt sur la messagerie instantanée, même si je pense que c'est en train de changer
comme peu de clients utilisent pubsub de manière intensive, il y a peu de demandes pour améliorer les implémentations côté serveurs
beaucoup de choses optionnelles, donc même si on a une implémentation, on n'a pas forcément ce que l'ont souhaite
il y a des choses comme les signets (bookmarks ou XEP-0048) qui au départ n'utilisaient pas pubsub - qui n'existait pas - et qui ont ensuite été mises à jour pour utiliser pubsub. Comme la première implémentation marche, beaucoup ne voient pas de raison de changer.
et surtout c'est un gros boulot, un projet à part entière, il faut les ressources pour implémenter pubsub + le boulot déjà existant sur le serveur.
Bref à mon sens c'est beaucoup plus logique d'avoir ça comme composant extérieur complet, que comme un parent pauvre du serveur. Et si on veut améliorer l'implémentation d'un serveur ça peut aller, mais tous les serveurs avec les dizaines de langages et d'architectures utilisés, c'est plus compliqué.
D'autre part, nous bougeons beaucoup sur PubSub, et il peut y avoir de nouvelles XEPs à implémenter, qui mettront du temps à arriver dans les serveurs: avec la maîtrise du composant, on peut faire une implémentation immédiatement (et pour tous les serveurs !), la chaîne de développement est beaucoup plus rapide.
Dans notre cas particulier, nous avons une extension non standard (pour le moment) qui permet d'envoyer un message à un groupe uniquement: vu qu'il n'y a pas de XEP associée, aucune chance de voir ça dans un serveur. Là on peut tester et améliorer avant de proposer une XEP.
Enfin oui ces 2 XEPs sont beaucoup plus faciles à implémenter (il m'a fallu quelques jours pour Prosody alors que ce sont mes premiers modules pour ce serveur), regarde leur taille et compare à la XEP-0060 pour comprendre, et ça peut servir dans d'autres cas qu'un composant PEP/PubSub. D'autre part tout ce qui est nécessaire à faire un service PEP est obligatoire dans ces XEPs, alors que tout ce dont on a besoin dans PubSub ne l'est pas forcément. Donc si elles sont implémentées, on est sûr d'avoir ce qu'il faut.
[^] # Re: Adhésions ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4.
Oui c'est un peu ça. Vous pouvez lire les statuts et le règlement intérieur pour mieux comprendre: les membres du bureau (un bureau collégial qui prend les décisions au consensus) sont les membres actifs, et ceux qui seront (on l'espère) salariés: si on a suffisamment de sous à terme et qu'on veut salarier quelqu'un d'autre, il sera membre du bureau.
Les adhérents n'ont aucun obligation de participation, même si on a une liste de diffusion pour les adhérents et qu'on aimerait les rencontrer régulièrement.
Nous avons choisi la forme associative pour plusieurs raisons: déjà c'est très facile à créer, d'autre part c'est assez souple pour s'organiser comme on le souhaite, ensuite le but non lucratif même s'il ne protège pas de tout évite au moins l'actionnariat (ce que nous voulions) et d'accumuler l'argent n'importe comment. Il y a aussi d'autres avantages: le don à une entreprise n'est pas possible ou très difficile alors que possible pour une association. Ici l'adhésion est une forme de soutien tout à fait légal (mais nous paieront des impôts dessus une fois salariés, ce qui est tout à fait normal).
Autre chose: il est très difficile de transférer le capital d'une association sauf vers une coopérative. Or nous envisageons la coopérative à terme.
Bref, vois l'association comme une façon de « tester » l'activité, et comme un cadre légal, et l'adhésion comme un moyen de nous soutenir.
Ah aussi je précise qu'on aimerait un don régulier, mais annuel: on a une fourchette de dons qui va de 0 à 100, mais on espère une moyenne de 10€/adhérent/an, autrement dit même pas un café par mois ! Nous ferons un rappel à chaque adhérent tous les ans (pas du spam, un rappel gentil :)), sans aucune obligation de redonner ou de donner le même montant (on peut donner 10 € un an et rester adhérent pour 0 € l'année suivante, ou ne plus être adhérent du tout).
Voilà, j'espère que c'est plus clair. Nous envisageons le financement participatif pour nous lancer également…
[^] # Re: Excellent travail
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 5.
Oui c'est assez sympa de se dire qu'on va pouvoir discuter ensemble et faire un réseau plus large en dehors de la messagerie instantanée où c'était déjà le cas.
Je pense que d'autres projets vont suivre: du côté de Poezio (très bon client XMPP console pour ceux qui lisent), ils ont commencé à parler d'une implémentation du microblogage également, j'aimerais beaucoup voir ça dans Gajim aussi, mais la dernière fois que j'en ai parlé au dév principal (il y a plusieurs années tout de même), il n'en était pas question, ils voulaient se concentrer sur la messagerie/vidéo conf (ce qui est un choix tout à fait compréhensible).
Pour ceux qui lisent ce commentaire, il y a d'autres point sur lesquels on avance, notamment avec edhelas (et quelques autres personnes) on est en train d'essayer de revoir les signets (bookmarks).
[^] # Re: Pourquoi
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 2.
C'était juste une explication comme ça, je ne pensais pas que ça valait le coup d'en faire une dépêche :).
Tiens pendant que je suis là, souliane me fait remarquer que
leur propre protocoles => leurs propres protocoles
si un modérateur pouvait corriger…
j'ai vu aussi une ou deux autres fautes/typos mais je ne sais plus où et je n'ai pas le courage de tout relire :)
[^] # Re: Plutôt bonne nouvelle en fait.
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal La publicité ciblée s'invite chez Firefox. Évalué à 4.
C'est faux ça. Tu peux très bien te rémunérer en étant au conseil d'administration, c'est d'ailleurs ce qu'on espère faire avec « Salut à Toi ». Tu n'as effectivement pas d'actionnariat dans une association type loi 1901 et tu ne peux pas accumuler de l'argent dans le vide, il faut des projets. Bref tu ne peux pas faire n'importe quoi, et si l'association est dissoute, tu ne peux pas filer l'argent qu'elle a à n'importe qui et n'importe comment.
Dans des cas très particuliers (comme association d'intérêt général). Dans notre cas en se salariant en étant au conseil d'administration, nous aurons une « gestion intéressée » et serons soumis aux impôts divers au même titre qu'une entreprise classique, ce qui me semble tout à fait normal.
Il y a une loi qui est passée il y a un an environ sur l'économie sociale et solidaire, concernant surtout les coopératives il me semble, mais je n'ai pas encore regardé ça en détails.
Le paiement d'une cotisation n'est absolument pas obligatoire, ça dépend des statuts. Chez nous il ne l'est pas par exemple.
Je doute très fort que ce que tu dis soit possible en l'état. Après je ne suis pas spécialiste non plus, et il y a sûrement moyen de contourner l'esprit d'origine. Mais il y a un encadrement légal ça c'est sûr. Je suppose que beaucoup de choses se font pas manque de contrôles aussi…
Ça c'est plutôt vrai, ça ne donne qu'un cadre légal. L'entreprise ou assimilé est ce qu'on en fait derrière, et dans tous les cas il y a probablement moyen de contourner et détourner des choses tant qu'on n'est pas pris…
Statut différent, pas nécessairement plus ou moins avantageux. Le but non lucratif a un sens légal et ce n'est pas rien. Mais une SARL peux être bien plus éthique qu'une association selon la façon dont elle est dirigée.
Après but non lucratif ça ne veut pas dire ne pas se salarier, ça veut dire qu'amasser de l'argent n'est pas le but de l'entité.
# [Libération.fr] Miracles et mirages du «crowdsourcing»
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Revue de presse de l'April pour la semaine 19 de l'année 2015. Évalué à 3.
Merci pour avoir relayé cet article intéressant et politique, qui sort un peu des dépêches AFP à peine réécrites habituelles.
On voit ici l'un des effets pervers et dangereux du développement d'internet, ou plutôt de son utilisation par certaines entreprises (parce qu'au final ce n'est pas internet le problème, mais bien l'utilisation par A. - et beaucoup d'autres ! - pour casser le droit du travail et profiter de la misère). Alors que d'un autre côté il y a des exemples superbes comme Wikipédia (qui a ses défauts, mais est globalement une réussite énorme).
Raison de plus pour boycotter cette multinationale et celles qui ont un comportement similaire.
# Gloup ! Gloup !
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Enfin une solution pour du café libre au boulot.. Évalué à 10.
Georges Le Gloupier travaille chez vous ?
[^] # Re: Pyjamas
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche RapydScript, le JavaScript qui se déguise en Python. Évalué à 2.
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
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche RapydScript, le JavaScript qui se déguise en Python. Évalué à 10.
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…
# Konsole + Yakuake
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quel terminal utilisez-vous ?. Évalué à 6.
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.
[^] # Re: Surtout les news
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Je déteste le premier avril. Évalué à 5.
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.
# on va manger des chips
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Pour plus de sécurité au bureau, évitez les chips (ou alors, chuchotez) !. Évalué à 4.
(désolé pour le site lié) on va manger des chips !
[^] # Re: Et en pratique ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Pour plus de sécurité au bureau, évitez les chips (ou alors, chuchotez) !. Évalué à 7. Dernière modification le 23 février 2015 à 10:24.
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.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 3.
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.
Friendica est toujours là, ainsi que redmatrix, le projet lié.
Non, ça c'est si tu veux contribuer au standard, et c'est un cas plutôt rare
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.
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).
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.
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.
on n'est pas du tout au même niveau. XMPP peut très bien utiliser WebSocket et WebRTC (Movim le fait d'ailleurs).
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…
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 3.
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.
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 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.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 7.
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.
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.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 2.
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.
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).
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).
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 2.
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 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).
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 2.
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.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 3.
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.
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.