Ce que tu demande ce ne serait pas surtout une plateforme communautaire sur la quelle tout le monde pourrait pousser ses données et qui serait du coup gérées par une communauté (gestion des formats, des demandes de corrections, API standardisées, etc) ?
En même temps combien il y a d'instances de serveurs un peu reconnus (dont on peut imaginer sans trop s'avancer qu'il ne va pas fermer d'ici la fin de l'année) ?
Que veux-tu dire ? Qu'il manque des aspects pour que tracim puisse être avantageux par rapport à votre wiki ? Que de toute façon, le wiki répond à tous vos besoins ? Autre chose ?
Je ne vois pas de fonction vraiment manquante. C'est plus un peu trop différent pour être accepté dans une équipe déjà organisée. Notre wiki est loin d'être parfait, mais les inconvénients ne nous bloque pas particulièrement. La documentation et la prise de décision n'est pas un enjeu fort de mon travail actuel.
En tout cas merci pour tes retours détaillés.
Je vous souhaite vraiment une bonne continuation de ce projet. À l'avenir c'est probablement une solution que je proposerais pour gérer la documentation (en concurrent de wiki et autre sharepoint).
Quand tu parles d'ouvrir les contenus pleine page, tu veux dire les ouvrir tels qu'actuellement (avec la timeline à droite) mais sur toute la largeur ou les ouvrir sans la timeline ? (Ou les deux).
Alors je ne sais pas pour lui, mais de ce que je viens de tester (la version en ligne que vous proposez). Quand j'ouvre un document mon écran est partagé en 4, de la gauche vers la droite : les espaces partagés, la liste des documents, le document et son historique. À peut prêt à 1/4 chacun1. Alors que si je viens de naviguer jusqu'à ce document c'est que c'est lui qui m'intéresse.
AMHA votre UI est très sympa, mais elle prend trop de place pour s'autoriser à montrer autant de choses à la fois. Sur ces 4 parties, il manque (toujours à mon très humble avis) une hiérarchisation plus clair de l'information présentée. Les espaces et la liste des documents pourraient prendre moins de place.
Pour la liste des documents, ça chatouille un peu. Le fait que le document actuellement vient par dessus, donne une impression que le document est dans une fenêtre "libre" (qu'on pourrait déplacer, agrandir, maximiser, etc).
Le fait d'ouvrir l'historique en même temps et au même niveau est une excellente idée je trouve. Sinon personne ne s'en servirait. 2 petites choses pourraient à mon avis encore l'améliorer :
valider un commentaire au clavier avec Ctrl+Enter par exemple
avoir une représentation du temps avec une flèche, je pense que ça peut mieux se comprendre que d'avoir à lire "historique" à la verticale
je ne sais pas si ça existe, mais avoir un élément dans l'historique qui montre que le temps a passé entre 2 évènements pourrait être très utile (ne rien mettre s'il s'est passé juste quelques minutes ou jours, mais s'il s'est passé 2 ans c'est une information importante en soit)
Voila. Comme je sais que ça t'intéresse. Je m'y intéresse parce que je m'intéresse toujours aux outils plus efficaces que ceux que j'utilise. Actuellement je n'ai pas l'impression de pouvoir pousser cet outil dans mon équipe. Un wiki nous convient bien.
Je pense que la contrainte qui consiste à s'organiser uniquement par espaces partagés peut être une force là où les wiki sont probablement trop arborescents (avec une arborescence trop profonde).
Je viens de refaire un test avec un écran plus grand en fait c'est différent sur les grands écrans. Pour info mon premier essaie était avec un 1920x1080 et mon second avec un 2560x1440. ↩
Il y a quelques temps au lieu d'utiliser matplotlib, j'avais utilisé pygal qui a des rendus assez jolis je trouve (et qui génère du svg de base c'est assez pratique pour moi).
Cet écosystème est aussi mis à disposition comme service par certains cloud providers. La partie machine learning d'Azure met à disposition NumPy, Pandas et IPython (au moins) pour manipuler les données et Google permet l'intéraction entre BigQuery et cet environnement.
Autant ton commentaire précédent pouvait être pertinent autant avec celui-ci…
La question n'est pas d'empêcher une application de faire une action, mais que la liste des actions don't elle a besoin soit suffisamment spécifié pour pouvoir s'assurer qu'elle n'est pas corrompu. Ton argument marcherait aussi bien avec les droit unix. Pourquoi interdire à tel ou tel programme d'accéder à tel ou tel répertoire ?
Si tu arrive à prendre le contrôle d'un programme/conteneur/machine virtuel, pouvoir ouvrir n'importe quel connexion vers l’extérieur représente un gros danger en terme de sécurité. Si tu le fait sur un serveur ssh par exemple, tu ne pourra pas le faire sans casser le comportement du serveur en question, ce qui augmente les chances de découvrir rapidement le problème.
Mais il est vrai (et c'est en ça que ton premier commentaire était juste), que tu peux le faire au niveau d'IP avec un firewall.
c'est débile !
Le contrôle du comportement d'un programme, c'est la base de la sécurité (ce que tu as avec les droits unix, avec les lsm, avec les gr security, avec seccomp, etc).
Je déteste la communication de ce projet. Il faut chercher pour trouver de quoi il s'agit. On voit vite que c'est un truc qui s'installe sur RPi, mais faut descendre dans le README.md du projet core sur github pour trouver qu'il s'agit d'un DNS (je me demandais s'il s'agissait d'un DNS, d'un proxy ou autre) avec éventuellement un serveur DHCP.
Mais ça c'est évident, perso je ne critique pas ce genre de points de vue. Je critique le fait que si une fonctionnalité existe sous X11 et Wayland, et que cela ne fonctionne pas bien avec KDE sous Wayland, cela n'est pas de la faute de Wayland. C'est KDE qui a raté quelque chose et qui doit le corriger.
On ne se place pas au même point de vu.
Pour moi d'un point de vu utilisateur, on a un X11/KDE qui a une fonctionnalité et un Wayland/KDE qui ne l'a pas. Donc l'arrivée de Wayland a cassé la fonctionnalité. Ce n'est peut être pas un bug de Wayland. On peut dire que c'est la carte graphique, son driver, les développeurs de KDE, les mainteneurs de la distribution qui ont foiré leur boulot, mais ça ne change pas le point que c'est l'arrivée de Wayland qui pète les compatibilités. Encore une fois c'est exactement ce qu'il s'est passé pour systemd.
Pour toi il y a un bug dans KDE et KDE doit le corriger. C'est le point de vu développeur. J'en suis tout à fait d'accord. Mais quoi qu'il arrive c'est l'arrivée de Wayland qui aura causé un bug, qui aura poussé GNOME a changé d'architecture, etc. Ce n'est pas un bug et je n'ai aucun doute que c'est pour du mieux.
Wayland veux changer le monde graphique sous linux, est-ce qu'on a le droit de dire que les changements qu'ils faut pour être compatibles avec lui viennent du fait de Wayland ?
D'ailleurs, le cas précédent est similaire à celui de Wayland / X11.
Wayland est présenté partout comme un remplaçant à X11 pas une alternative. Je dis juste qu'il y a beaucoup de choses à redévelopper pour pouvoir supporter Wayland (que c'est quelque chose à prendre en compte dans la migration vers wayland).
J'ai pas compris pourquoi ça fais de moi un complotiste.
Tu es entrain de dire que ce n'est pas un bug. Pas que ce n'est pas leur faute. C'est différent.
Ils cassent volontairement tous les bureaux. C'est eux qui cassent les fonctionnalités ça leur est imputable.
Ton message au quel je répondais tenter de faire passer une réécriture d'une fonctionnalité pour être compatible avec l'API de Wayland comme n'étant pas de la faute à Wayland.
Il serait peut être bon sur le sujet de ne pas tout mettre sur le dos de Wayland…
Alors si. Les impacts sur le système de la réécriture d'un composant est tout à fait à mettre sur le compte de ce nouveau composant. Quand l'arrivée de wayland demande à tous les outils classiques de faire des adaptations pour pouvoir produire les même fonctionnalités que ce qu'ils avaient avant, on peut difficilement dire que wayland n'y est pour rien. De la même manière que lorsque systemd arrive est casse de précédentes fonctionnalités c'est de la faute de systemd.
Aux développeurs d'assumer et d'avoir de bonnes raisons de causer ces régressions.
Puisque que tu t'intéresse à la technique il semble. Prends quelques minutes pour regarder un peu plus en détaille d'où ça peut venir. Par exemple avec about:performance tu peux avoir une petite idée de la consommation mémoire de chaque onglet et chaque add-on. On peut avoir certaines surprises avec ça. Par exemple certaines pages de jenkins peuvent devenir très lourdes avec le temps (une forme de fuite mémoire, ça fonctionne bien, mais si tu reste la journée sur la page qui se met à jour automatiquement toute seule, elle commence à consommer énormément de mémoire).
Firefox est un interpréteur de site. Il consomme potentiellement trop, mais en soit donner juste sa consommation sans savoir l'usage qui en est fait ne donne pas beaucoup d'informations sur sa performance. Si tu lui demande beaucoup ça ne m'étonne pas qu'il consomme beaucoup (même s'il est probablement sous optimal).
je commence à swapper (sur mon SSD, c'est ballot…
C'est toi qui a créé ta partition de swap sur ton SSD, non ?
Ça n'a rien demandé comme adaptation au niveau du réseau.
Passer de quelques milliers de messages par jours à quelques millions avec de gros pics ? Se mettre à router ses messages entre opérateurs ? Permettre à des tiers de se connecter à se réseau pour faire des numéros cours et gérer des serveurs de SMS ?
Oui je suis sûr que ça n'a pas demandé d'adaptation, ou alors vraiment très peu.
Non on parle de techno, je vous surtout des gens dire que c'est pas bien d'utiliser imap pour du chat et vendre d'utiliser xmpp pour du mail. Donc on a le droit de tordre les protocoles ou pas ? Dire que ça doit être dans le client c'est bien mais quel client le fait ? Comment tu suit plusieurs conversations différentes avec un seul et même destinataire ? Avec plusieurs tu dois perpétuellement créer des conversations ?
On peut implémenter IP au dessus de XMPP, donc oui on peut tout imaginer mais qu'est ce qui existe à l'heure actuelle ? Pourquoi est-ce que toutes ces bonnes idées ne sont pas implémenter ?
Se plaindre du tout http c'est une chose mais si c'est pour le remplacer par du tout xmpp ça ne change pas fondamentalement le problème.
Tu lis comment tes messages XMPP hors connexion ?
Tu fais comment pour trier tes messages XMPP ?
Le forward de message tu le fais par copier/coller ?
Les mailing list c'est différent des salons.
C'est surtout que XMPP avait image de protocol de chat only pendant 10ans.
Non c'est qu'il a passé 10 ans à tenter d'être un protocole de chat avant de se dire qu'il pourrait réinventer la roue lui aussi.
Si on parle en pourcentage, je pense que le message avec juste "salut" gagne haut la main. Surtout s'il passe par des prestataires gourmands en headers rajoutés par leur système de mail comme outlook. On doit facilement atteindre le mail de 5ko pour 5o de données utiles.
Les SMS ne sont pas particulièrement mieux, je ne vois pas d'intifada écologique contre l'usage de ces protocoles pourtant particulièrement coûteux. Les protocoles comme XMPP demandent le maintiens d'une connexion avec éventuellement des ping réguliers (en plus pour XMPP le fait d'utiliser XML pas particulièrement compact ni léger en temps de traitement).
La question écologique est intéressante mais il faut véritablement comparer plutôt que de sortir des trucs à l'emporte pièce.
Oula je ne dois pas que ce qu'il décrit est fondamentalement inintéressant juste qu'il n'a probablement pas suffisamment mis en évidence le lien avec le contenu du journal.
Le journal comme tu le cite parle d'interopérabilité et pas d'ouverture. C'est assez différent sans être antinomique.
Dis plus clairement : ce qui fait qu'une solution de communication marche ou pas est sa quantité d'utilisateurs. Avoir une démarche pour maximiser son nombre d'utilisateurs est vraiment important. Sachant que faire déplacer les utilisateurs d'ICQ, MSN, bbm, hangout, slack, fb messenger, WhatsApp sans avoir la force de frappe d'un GAFAM est très compliqué. Donc une démarche comme xmpp (un standard et une fédération pour que les instances ne soient pas concurrentes) ou comme delta (utilisation de protocoles déjà massivement utilisés est intéressant).
Que propose Matrix pour cet aspect particulier ? Qu'est ce qui fais que les gens vont pouvoir utiliser Matrix ? Il y a des passerelles vers WhatsApp, hangout et fb messenger ?
(à noter que je n'est pas inutilé moi même juste tenté de répondre à la question de l'auteur du commentaire)
[^] # Re: Je me demande
Posté par barmic . En réponse au journal 6 avril 2019 : C'est le 2e GPS Week Number Rollover. Évalué à 8.
Je pensais que l'aérospatial était plus fiable que ça sur la gestion du temps. S'ils ont les même problème que nous, c'est « rassurant » :D
# Plateforme communautaire
Posté par barmic . En réponse au journal Données Libres : Analyse critique de l’open data. Évalué à 3.
Ce que tu demande ce ne serait pas surtout une plateforme communautaire sur la quelle tout le monde pourrait pousser ses données et qui serait du coup gérées par une communauté (gestion des formats, des demandes de corrections, API standardisées, etc) ?
[^] # Re: et au final ça fait quoi ?
Posté par barmic . En réponse au journal 6 avril 2019 : C'est le 2e GPS Week Number Rollover. Évalué à 2.
En fait il change d'Epoch tous les 20 ans, donc j'imagine que, tous les 20 ans, il faut redéfinir l'Epoch de chaque GPS.
Je ne sais pas, mais déjà les alternatives au GPS n'ont apparemment pas ce problème : https://www.guralp.com/howtos/gps-wnro.shtml
[^] # Re: Bonne nouvelle !
Posté par barmic . En réponse au journal Dino, le client XMPP, est disponible sur plusieurs distributions GNU/Linux. Évalué à 3.
En même temps combien il y a d'instances de serveurs un peu reconnus (dont on peut imaginer sans trop s'avancer qu'il ne va pas fermer d'ici la fin de l'année) ?
[^] # Re: Wiki sans liens ?
Posté par barmic . En réponse à la dépêche Collaboration laborieuse ? Si les symptômes persistent, installez Tracim 2.1 !. Évalué à 3.
Je ne vois pas de fonction vraiment manquante. C'est plus un peu trop différent pour être accepté dans une équipe déjà organisée. Notre wiki est loin d'être parfait, mais les inconvénients ne nous bloque pas particulièrement. La documentation et la prise de décision n'est pas un enjeu fort de mon travail actuel.
Je vous souhaite vraiment une bonne continuation de ce projet. À l'avenir c'est probablement une solution que je proposerais pour gérer la documentation (en concurrent de wiki et autre sharepoint).
[^] # Re: Wiki sans liens ?
Posté par barmic . En réponse à la dépêche Collaboration laborieuse ? Si les symptômes persistent, installez Tracim 2.1 !. Évalué à 3.
Alors je ne sais pas pour lui, mais de ce que je viens de tester (la version en ligne que vous proposez). Quand j'ouvre un document mon écran est partagé en 4, de la gauche vers la droite : les espaces partagés, la liste des documents, le document et son historique. À peut prêt à 1/4 chacun1. Alors que si je viens de naviguer jusqu'à ce document c'est que c'est lui qui m'intéresse.
AMHA votre UI est très sympa, mais elle prend trop de place pour s'autoriser à montrer autant de choses à la fois. Sur ces 4 parties, il manque (toujours à mon très humble avis) une hiérarchisation plus clair de l'information présentée. Les espaces et la liste des documents pourraient prendre moins de place.
Pour la liste des documents, ça chatouille un peu. Le fait que le document actuellement vient par dessus, donne une impression que le document est dans une fenêtre "libre" (qu'on pourrait déplacer, agrandir, maximiser, etc).
Le fait d'ouvrir l'historique en même temps et au même niveau est une excellente idée je trouve. Sinon personne ne s'en servirait. 2 petites choses pourraient à mon avis encore l'améliorer :
Voila. Comme je sais que ça t'intéresse. Je m'y intéresse parce que je m'intéresse toujours aux outils plus efficaces que ceux que j'utilise. Actuellement je n'ai pas l'impression de pouvoir pousser cet outil dans mon équipe. Un wiki nous convient bien.
Je pense que la contrainte qui consiste à s'organiser uniquement par espaces partagés peut être une force là où les wiki sont probablement trop arborescents (avec une arborescence trop profonde).
Je viens de refaire un test avec un écran plus grand en fait c'est différent sur les grands écrans. Pour info mon premier essaie était avec un 1920x1080 et mon second avec un 2560x1440. ↩
# Grave
Posté par barmic . En réponse au journal Le flicage dans l'Open Source. Évalué à 10.
Ça c'est un journal qui dénonce grave !
[^] # Re: Outils complémentaires
Posté par barmic . En réponse à la dépêche Python pour les sciences, une présentation. Évalué à 6.
Il y a quelques temps au lieu d'utiliser matplotlib, j'avais utilisé pygal qui a des rendus assez jolis je trouve (et qui génère du svg de base c'est assez pratique pour moi).
# Python as a Service
Posté par barmic . En réponse à la dépêche Python pour les sciences, une présentation. Évalué à 4.
Cet écosystème est aussi mis à disposition comme service par certains cloud providers. La partie machine learning d'Azure met à disposition NumPy, Pandas et IPython (au moins) pour manipuler les données et Google permet l'intéraction entre BigQuery et cet environnement.
[^] # Re: Comment "démasquer" un faux visage
Posté par barmic . En réponse au journal Cette personne n'existe pas. Évalué à 4.
J'avoue que les oreilles sont régulièrement ratées. Je ne m'en était pas rendu compte avant que tu ne mette le doigt dessus.
[^] # Re: L’avenir et le passé
Posté par barmic . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 3.
Autant ton commentaire précédent pouvait être pertinent autant avec celui-ci…
La question n'est pas d'empêcher une application de faire une action, mais que la liste des actions don't elle a besoin soit suffisamment spécifié pour pouvoir s'assurer qu'elle n'est pas corrompu. Ton argument marcherait aussi bien avec les droit unix. Pourquoi interdire à tel ou tel programme d'accéder à tel ou tel répertoire ?
Si tu arrive à prendre le contrôle d'un programme/conteneur/machine virtuel, pouvoir ouvrir n'importe quel connexion vers l’extérieur représente un gros danger en terme de sécurité. Si tu le fait sur un serveur ssh par exemple, tu ne pourra pas le faire sans casser le comportement du serveur en question, ce qui augmente les chances de découvrir rapidement le problème.
Mais il est vrai (et c'est en ça que ton premier commentaire était juste), que tu peux le faire au niveau d'IP avec un firewall.
Le contrôle du comportement d'un programme, c'est la base de la sécurité (ce que tu as avec les droits unix, avec les lsm, avec les gr security, avec seccomp, etc).
[^] # Re: Sites et marketing
Posté par barmic . En réponse au journal Sécurité, vie privée... et Google Analytics!. Évalué à 6.
Je déteste la communication de ce projet. Il faut chercher pour trouver de quoi il s'agit. On voit vite que c'est un truc qui s'installe sur RPi, mais faut descendre dans le README.md du projet core sur github pour trouver qu'il s'agit d'un DNS (je me demandais s'il s'agissait d'un DNS, d'un proxy ou autre) avec éventuellement un serveur DHCP.
[^] # Re: KDE et wayland
Posté par barmic . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 2.
On ne se place pas au même point de vu.
Pour moi d'un point de vu utilisateur, on a un X11/KDE qui a une fonctionnalité et un Wayland/KDE qui ne l'a pas. Donc l'arrivée de Wayland a cassé la fonctionnalité. Ce n'est peut être pas un bug de Wayland. On peut dire que c'est la carte graphique, son driver, les développeurs de KDE, les mainteneurs de la distribution qui ont foiré leur boulot, mais ça ne change pas le point que c'est l'arrivée de Wayland qui pète les compatibilités. Encore une fois c'est exactement ce qu'il s'est passé pour systemd.
Pour toi il y a un bug dans KDE et KDE doit le corriger. C'est le point de vu développeur. J'en suis tout à fait d'accord. Mais quoi qu'il arrive c'est l'arrivée de Wayland qui aura causé un bug, qui aura poussé GNOME a changé d'architecture, etc. Ce n'est pas un bug et je n'ai aucun doute que c'est pour du mieux.
Wayland veux changer le monde graphique sous linux, est-ce qu'on a le droit de dire que les changements qu'ils faut pour être compatibles avec lui viennent du fait de Wayland ?
[^] # Re: KDE et wayland
Posté par barmic . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 4.
Wayland est présenté partout comme un remplaçant à X11 pas une alternative. Je dis juste qu'il y a beaucoup de choses à redévelopper pour pouvoir supporter Wayland (que c'est quelque chose à prendre en compte dans la migration vers wayland).
J'ai pas compris pourquoi ça fais de moi un complotiste.
[^] # Re: KDE et wayland
Posté par barmic . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 1.
Tu es entrain de dire que ce n'est pas un bug. Pas que ce n'est pas leur faute. C'est différent.
Ils cassent volontairement tous les bureaux. C'est eux qui cassent les fonctionnalités ça leur est imputable.
Ton message au quel je répondais tenter de faire passer une réécriture d'une fonctionnalité pour être compatible avec l'API de Wayland comme n'étant pas de la faute à Wayland.
[^] # Re: KDE et wayland
Posté par barmic . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 8.
Alors si. Les impacts sur le système de la réécriture d'un composant est tout à fait à mettre sur le compte de ce nouveau composant. Quand l'arrivée de wayland demande à tous les outils classiques de faire des adaptations pour pouvoir produire les même fonctionnalités que ce qu'ils avaient avant, on peut difficilement dire que wayland n'y est pour rien. De la même manière que lorsque systemd arrive est casse de précédentes fonctionnalités c'est de la faute de systemd.
Aux développeurs d'assumer et d'avoir de bonnes raisons de causer ces régressions.
[^] # Re: userland
Posté par barmic . En réponse au journal Mon retour sous KDE. Évalué à 4.
Puisque que tu t'intéresse à la technique il semble. Prends quelques minutes pour regarder un peu plus en détaille d'où ça peut venir. Par exemple avec
about:performancetu peux avoir une petite idée de la consommation mémoire de chaque onglet et chaque add-on. On peut avoir certaines surprises avec ça. Par exemple certaines pages de jenkins peuvent devenir très lourdes avec le temps (une forme de fuite mémoire, ça fonctionne bien, mais si tu reste la journée sur la page qui se met à jour automatiquement toute seule, elle commence à consommer énormément de mémoire).Firefox est un interpréteur de site. Il consomme potentiellement trop, mais en soit donner juste sa consommation sans savoir l'usage qui en est fait ne donne pas beaucoup d'informations sur sa performance. Si tu lui demande beaucoup ça ne m'étonne pas qu'il consomme beaucoup (même s'il est probablement sous optimal).
C'est toi qui a créé ta partition de swap sur ton SSD, non ?
[^] # Re: Consommation de ressources
Posté par barmic . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 3.
Ils ne l'auraient pas fait sur les autres protocoles ?
[^] # Re: nvidia
Posté par barmic . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 3.
T'en a aucune idée. Tu ne sais pas si la totalité de ce code est la propriété d'nvidia. Ils peuvent avoir légalement l'interdiction de le libérer.
[^] # Re: Consommation de ressources
Posté par barmic . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 7.
Passer de quelques milliers de messages par jours à quelques millions avec de gros pics ? Se mettre à router ses messages entre opérateurs ? Permettre à des tiers de se connecter à se réseau pour faire des numéros cours et gérer des serveurs de SMS ?
Oui je suis sûr que ça n'a pas demandé d'adaptation, ou alors vraiment très peu.
[^] # Re: Consommation de ressources
Posté par barmic . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 3.
Non on parle de techno, je vous surtout des gens dire que c'est pas bien d'utiliser imap pour du chat et vendre d'utiliser xmpp pour du mail. Donc on a le droit de tordre les protocoles ou pas ? Dire que ça doit être dans le client c'est bien mais quel client le fait ? Comment tu suit plusieurs conversations différentes avec un seul et même destinataire ? Avec plusieurs tu dois perpétuellement créer des conversations ?
On peut implémenter IP au dessus de XMPP, donc oui on peut tout imaginer mais qu'est ce qui existe à l'heure actuelle ? Pourquoi est-ce que toutes ces bonnes idées ne sont pas implémenter ?
Se plaindre du tout http c'est une chose mais si c'est pour le remplacer par du tout xmpp ça ne change pas fondamentalement le problème.
[^] # Re: Consommation de ressources
Posté par barmic . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 8.
Tu lis comment tes messages XMPP hors connexion ?
Tu fais comment pour trier tes messages XMPP ?
Le forward de message tu le fais par copier/coller ?
Les mailing list c'est différent des salons.
Non c'est qu'il a passé 10 ans à tenter d'être un protocole de chat avant de se dire qu'il pourrait réinventer la roue lui aussi.
[^] # Re: Consommation de ressources
Posté par barmic . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 7.
Les SMS ne sont pas particulièrement mieux, je ne vois pas d'intifada écologique contre l'usage de ces protocoles pourtant particulièrement coûteux. Les protocoles comme XMPP demandent le maintiens d'une connexion avec éventuellement des ping réguliers (en plus pour XMPP le fait d'utiliser XML pas particulièrement compact ni léger en temps de traitement).
La question écologique est intéressante mais il faut véritablement comparer plutôt que de sortir des trucs à l'emporte pièce.
[^] # Re: ordinateur réchauffe-moi !
Posté par barmic . En réponse au journal Debian et l'intégration continue. Évalué à 3.
Ils vont consommer plus d'eau chaude que ce qu'ils vint aider à produire.
[^] # Re: Matrix/Riot
Posté par barmic . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 8.
Oula je ne dois pas que ce qu'il décrit est fondamentalement inintéressant juste qu'il n'a probablement pas suffisamment mis en évidence le lien avec le contenu du journal.
Le journal comme tu le cite parle d'interopérabilité et pas d'ouverture. C'est assez différent sans être antinomique.
Dis plus clairement : ce qui fait qu'une solution de communication marche ou pas est sa quantité d'utilisateurs. Avoir une démarche pour maximiser son nombre d'utilisateurs est vraiment important. Sachant que faire déplacer les utilisateurs d'ICQ, MSN, bbm, hangout, slack, fb messenger, WhatsApp sans avoir la force de frappe d'un GAFAM est très compliqué. Donc une démarche comme xmpp (un standard et une fédération pour que les instances ne soient pas concurrentes) ou comme delta (utilisation de protocoles déjà massivement utilisés est intéressant).
Que propose Matrix pour cet aspect particulier ? Qu'est ce qui fais que les gens vont pouvoir utiliser Matrix ? Il y a des passerelles vers WhatsApp, hangout et fb messenger ?
(à noter que je n'est pas inutilé moi même juste tenté de répondre à la question de l'auteur du commentaire)