Edhelas: thanks for list of XEPs. I think you are missing the point: the current typical dialect of XMPP revolves around 1:1 IMs and XEP-45 MUCs. If I am talking in a MUC with JID foo@bar.com and the server(s) at bar.com go down, i lose the whole conversation - including the conversation history if it's implementing XEP-313. This is a major design flaw: conversations should be owned by the people participating in them; not any single party or vendor. Plus with a decentralised approach you get offline operation and merging history after netsplits for free.
Sur l'idée d'avoir des MUC décentralisés je te l'accorde c'est bien sympa et en effet sur XMPP c'est pas pensé comme ça. Mais encore une fois ce sont des choses qui peuvent être imaginés et étendues sans soucis.
Concernant le fait de perdre l'historique si le serveur tombe, ce n'est pas totalement vrais. MAM permet de garder un historique sur notre propre serveur, même si le serveur distant n'est plus disponible.
You could implement these semantics on top of XMPP, which is what FMUC and BuddyCloud do - but you are effectively creating a whole new dialect (with very limited compatible server and client implementations, increasing fragmentation) just using XMPP as a basic message passing transport. So we decided to skip XMPP altogether and just use plain HTTP API with a higher set of baseline functionality (whilst still being extensible), rather than arbitrarily build on XMPP given the end result wouldn't be compatible with normal MUCs and XMPP IMs anyway. (We also only discovered the BC and FMUC XEPs after designing and launching Matrix).
C'est ici que je ne suis pas d'accord avec toi. XMPP (Extensible Messaging and Presence Protocol) n'est pas/plus Jabber. Aujourd'hui le "cœur Jabber" n'est plus qu'une petite partie du protocole, mais je te l'accorde ici aussi, oui ça a été construit "par dessus" donc il y a encore l'état d'esprit du protocole original.
Par ailleurs, XMPP n'a pas vocation a être implémenté dans sa totalité par les clients et serveurs, libre à vous de choisir/casser ce qui vous plait, ou pas, dans XMPP. Mais le fait de garder une architecture commune permet de limiter la difficulté quand il s'agira de construire les "ponts" entre les réseaux.
I'm sorry that the existence of Matrix seems to upset some people who have successfully invested in XMPP. If XMPP works for you, then we're very happy and we're not stopping you. And we'll provide an XMPP s2s to Matrix bridge to let you enjoy Matrix too.
In terms of your concerns on HTTP long polling: with HTTP/2 it's really not that bad and only slightly worse than websockets. And anyway we only mandate plain HTTP as a baseline protocol for compatibility - if you want to put JSON or capn proto over WS or COAP or MQTT or whatever than go for it :)
HTTP/2 est encore très loin d'être déployé et utilisé partout, mais en effet les avancées faites vont considérablement réduire la signalisation et le temps de latence lors de l'échange des données.
Dans mon projet j'ai fait le chemin inverse, je suis partit du long polling HTTP pour aller vers les WebSockets, puis sur du Socket simple. Pensez aussi aux mobiles, le long-polling implique systématiquement un "ping" pour savoir si la ressource est encore disponible, le mobile/navigateur risque donc d'envoyer des centaines/milliers de requêtes quotidiennement pour simplement garder une connexion ouverte sur le serveur.
Edhelas: this is the third time we've had the same discussion - if it still doesn't make sense please tell me what is confusing so we don't get stuck in groundhog day...
Oui nous en avons déjà parlé mais sans avoir le temps de creuser exactement les points où nous n'étions pas d'accord. Je sais que je donne des fois l'impression d'être quelqu'un de têtu mais je trouve dommage d'avoir un explosion de protocoles d'IM (tant libre que propriétaires) et de passer notre temps a écrire des librairies de transports alors qu'il existe déjà tout ce qu'il faut comme standard dans la nature.
Ne pas être d'accord ou essayer de penser "hors de la boite" est super, c'est d'ailleurs l'essence même de ce que fait le logiciel libre. Mais ce qui caractérise aussi le libre c'est l'utilisation des standards. On a réussit à se mettre d'accord sur beaucoup d'entre elles, mais ça bloque pour l'IM/social et ça fait maintenant 5 ans que je pense que XMPP a la possibilité de devenir une norme universelle au même niveau que IMAP/SMTP/POP ont fait ce qu'on appelle aujourd'hui "l'email".
D'ailleurs ce qui est rigolo c'est qu'une fois qu'une norme arrive a émerger, l'innovation tend à se faire finalement plus sur les clients avec le temps. IMAP/SMTP/POP ça n'a pas fondamentalement changé depuis des années, pourtant on a eu Outlook, Thunderbird, les webmails, les clients mobiles avec plein d'interfaces... pareil pour le Web, pendant des années on s'est tapé dessus pour normaliser tout ça et au final, une fois que tout le monde s'est mis d'accord (HTML5...) on a vu ce que ça a donné : des applications web dynamiques, des systèmes d'exploitation (FirefoxOS), des intégrations poussées (notification, visio-conférence...) sur toutes les plateformes inimaginables.
Donc oui les normes c'est chiant, mais on fait avec. Je vais te faire une confidence, je n'aime pas particulièrement certains trucs dans XMPP, j'ai déjà eu des échanges assez mouvementés avec la XSF (comme sur certains problèmes relatifs à PubSub http://wiki.xmpp.org/web/PubSubIssues ou sur les Bookmarks http://mail.jabber.org/pipermail/standards/2014-April/028833.html), mais bon je fais avec. Mais je préfère prendre du temps pour discuter, proposer des corrections et faire évoluer tout ça. Et finalement le temps que je vais prendre pour "casser des choses" dans XMPP sera tout autant de temps gagné pour les autres projets qui souhaitent intégrer ces fonctionnalités/changements.
[^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?
Posté par edhelas (site web personnel) . En réponse au journal Qui veux débattre Messagerie Instantané au Jardin Entropique. Évalué à 1.
Sur l'idée d'avoir des MUC décentralisés je te l'accorde c'est bien sympa et en effet sur XMPP c'est pas pensé comme ça. Mais encore une fois ce sont des choses qui peuvent être imaginés et étendues sans soucis.
Concernant le fait de perdre l'historique si le serveur tombe, ce n'est pas totalement vrais. MAM permet de garder un historique sur notre propre serveur, même si le serveur distant n'est plus disponible.
C'est ici que je ne suis pas d'accord avec toi. XMPP (Extensible Messaging and Presence Protocol) n'est pas/plus Jabber. Aujourd'hui le "cœur Jabber" n'est plus qu'une petite partie du protocole, mais je te l'accorde ici aussi, oui ça a été construit "par dessus" donc il y a encore l'état d'esprit du protocole original.
Par ailleurs, XMPP n'a pas vocation a être implémenté dans sa totalité par les clients et serveurs, libre à vous de choisir/casser ce qui vous plait, ou pas, dans XMPP. Mais le fait de garder une architecture commune permet de limiter la difficulté quand il s'agira de construire les "ponts" entre les réseaux.
Et je pense qu'il y aura également des transports XMPP vers le réseau Matrix :) Ce n'est pas la première fois qu'on essayera de créer un pont en utilisant une interface Web, je viens de packager 2 librairies (pour le réseau Skype et QQ) qui passent par une interface Web pour interagir avec leurs réseaux respectifs (voir http://edhelas.movim.eu/blog/?post/2015/06/06/Packaging%2C-d%C3%A9ploiement-et-int%C3%A9gration-de-nouveaux-transports-XMPP) .
HTTP/2 est encore très loin d'être déployé et utilisé partout, mais en effet les avancées faites vont considérablement réduire la signalisation et le temps de latence lors de l'échange des données.
Dans mon projet j'ai fait le chemin inverse, je suis partit du long polling HTTP pour aller vers les WebSockets, puis sur du Socket simple. Pensez aussi aux mobiles, le long-polling implique systématiquement un "ping" pour savoir si la ressource est encore disponible, le mobile/navigateur risque donc d'envoyer des centaines/milliers de requêtes quotidiennement pour simplement garder une connexion ouverte sur le serveur.
Oui nous en avons déjà parlé mais sans avoir le temps de creuser exactement les points où nous n'étions pas d'accord. Je sais que je donne des fois l'impression d'être quelqu'un de têtu mais je trouve dommage d'avoir un explosion de protocoles d'IM (tant libre que propriétaires) et de passer notre temps a écrire des librairies de transports alors qu'il existe déjà tout ce qu'il faut comme standard dans la nature.
Ne pas être d'accord ou essayer de penser "hors de la boite" est super, c'est d'ailleurs l'essence même de ce que fait le logiciel libre. Mais ce qui caractérise aussi le libre c'est l'utilisation des standards. On a réussit à se mettre d'accord sur beaucoup d'entre elles, mais ça bloque pour l'IM/social et ça fait maintenant 5 ans que je pense que XMPP a la possibilité de devenir une norme universelle au même niveau que IMAP/SMTP/POP ont fait ce qu'on appelle aujourd'hui "l'email".
D'ailleurs ce qui est rigolo c'est qu'une fois qu'une norme arrive a émerger, l'innovation tend à se faire finalement plus sur les clients avec le temps. IMAP/SMTP/POP ça n'a pas fondamentalement changé depuis des années, pourtant on a eu Outlook, Thunderbird, les webmails, les clients mobiles avec plein d'interfaces... pareil pour le Web, pendant des années on s'est tapé dessus pour normaliser tout ça et au final, une fois que tout le monde s'est mis d'accord (HTML5...) on a vu ce que ça a donné : des applications web dynamiques, des systèmes d'exploitation (FirefoxOS), des intégrations poussées (notification, visio-conférence...) sur toutes les plateformes inimaginables.
Donc oui les normes c'est chiant, mais on fait avec. Je vais te faire une confidence, je n'aime pas particulièrement certains trucs dans XMPP, j'ai déjà eu des échanges assez mouvementés avec la XSF (comme sur certains problèmes relatifs à PubSub http://wiki.xmpp.org/web/PubSubIssues ou sur les Bookmarks http://mail.jabber.org/pipermail/standards/2014-April/028833.html), mais bon je fais avec. Mais je préfère prendre du temps pour discuter, proposer des corrections et faire évoluer tout ça. Et finalement le temps que je vais prendre pour "casser des choses" dans XMPP sera tout autant de temps gagné pour les autres projets qui souhaitent intégrer ces fonctionnalités/changements.