Il me semble que le fait d'intégrer une passerelle à un serveur XMPP ne va pas dans le sens d'une philosophie KISS. Quel est l'intérêt de cette intégration par rapport à la mise en place d'une passerelle externe ?
Il faut bien voir que ejabberd est capable d'être distribué sur plusieurs machines, donc un bridge externe n'aurait pas la capacité de faire ça, sauf en dupliquant tout 2 fois dans 2 process séparés.
Ça ne me parait pas une architecture qui permet d'éviter les bugs (surtout que tu rajoute de la complexité en rajoutant un lien entre le serveur xmpp et le serveur matrix), ça serait comme demander à avoir un lecteur de vidéo par codec au nom d'une philosophie KISS :/
Qu'est-ce qu'on entend par passerelle dans ce contexte?
Au sens xmpp, il existe un mécanisme qui permet à un serveur xmpp de se connecter comme un client à un autre réseau de messagerie. Pour ça il faut ouvrir une session par utilisateur du serveur, et le serveur doit connaître (et stocker en clair) les mots de passe des services auxquels il se connecte.
Ici l'idée semble plutôt d'avoir une connexion serveur à serveur, ce qui se fait naturellement aussi bien dans Matrix que dans XMPP, tous deux étant des protocoles fédérés. Cela peut rendre les choses transparentes entre les deux protocoles: les clients xmpp pourront se connecter à des salons Matrix, et inversement, les salons de discussion du serveur xmpp seront disponibles directement via le réseau Matrix.
Je ne pense pas qu'une passerelle externe permettrait ce niveau d'intégration dans les 2 directions?
# implémenté sous forme d'une passerelle
Posté par Anonyme . Évalué à 2.
Il me semble que le fait d'intégrer une passerelle à un serveur XMPP ne va pas dans le sens d'une philosophie KISS. Quel est l'intérêt de cette intégration par rapport à la mise en place d'une passerelle externe ?
[^] # Re: implémenté sous forme d'une passerelle
Posté par Misc (site web personnel) . Évalué à 5.
Il faut bien voir que ejabberd est capable d'être distribué sur plusieurs machines, donc un bridge externe n'aurait pas la capacité de faire ça, sauf en dupliquant tout 2 fois dans 2 process séparés.
Ça ne me parait pas une architecture qui permet d'éviter les bugs (surtout que tu rajoute de la complexité en rajoutant un lien entre le serveur xmpp et le serveur matrix), ça serait comme demander à avoir un lecteur de vidéo par codec au nom d'une philosophie KISS :/
[^] # Re: implémenté sous forme d'une passerelle
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Qu'est-ce qu'on entend par passerelle dans ce contexte?
Au sens xmpp, il existe un mécanisme qui permet à un serveur xmpp de se connecter comme un client à un autre réseau de messagerie. Pour ça il faut ouvrir une session par utilisateur du serveur, et le serveur doit connaître (et stocker en clair) les mots de passe des services auxquels il se connecte.
Ici l'idée semble plutôt d'avoir une connexion serveur à serveur, ce qui se fait naturellement aussi bien dans Matrix que dans XMPP, tous deux étant des protocoles fédérés. Cela peut rendre les choses transparentes entre les deux protocoles: les clients xmpp pourront se connecter à des salons Matrix, et inversement, les salons de discussion du serveur xmpp seront disponibles directement via le réseau Matrix.
Je ne pense pas qu'une passerelle externe permettrait ce niveau d'intégration dans les 2 directions?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.