Si j'ai bien compris, SàT est à la base un démon qui fait client XMPP, sur lequel se connectent des backends (un mot Français pour traduire ça??) variés.
Presque, ce sont des frontends (interfaces) qui se connectent, et le démon est le backend
SàT ne serait donc pas un projet destiné à apporter à XMPP les fonctionnalités haut niveau que tu souhaitais et qui n'étaient pas implémentées de base?
Non, c'est bel est bien un client. Tu pourrais remplacer le couple démon/D-Bus par bibliothèque ça reviendrait au même.
Un serveur XMPP communique avec un client de manière faite pour le réseau, alors que le démon communique avec les interfaces en se considérant en local (même si ce serait techniquement possible d'avoir des interfaces à distance, mais c'est une autre histoire), des messages sont envoyés en permanence pour D-Bus, des signaux pour le moindre texte envoyé ou reçu. Le démon gère des choses qui n'ont rien à voir avec XMPP: par exemple les plugins peuvent fournir des UI génériques aux frontends, j'ai un plugin qui permet de lire/envoyer des messages couchsurfing, ou de se créer des serveurs IMAP/SMTP, ce n'est pas du tout le rôle du serveur XMPP de faire tout ça.
Pareil, le démon gère le stockage et la manipulation de l'historique, ou de ton roster.
SàT ne serait donc pas un projet destiné à apporter à XMPP les fonctionnalités haut niveau que tu souhaitais et qui n'étaient pas implémentées de base?
Les fonctionnalités que je désire et qui ne sont pas implémentées de base dans le serveur, c'est via des extensions au protocoles (des XEPs) que je les implémenterai (modulo la XEP est validée).
SàT est vraiment un client, il a juste une séparation forte entre la vue et le métier, ou entre la vue et le couple modèle/contrôleur dans un modèle MVC.
Parce que, par exemple, avoir la même conversation qui s'affiche partout, ça devrait être d'office dans XMPP (c'est le comportement qui me semblerait logique en mettant la même priorité à plusieurs clients en même temps ; mais bon, la logique, ça peut être subjectif...).
Une priorité positive égale ça pourrait envoyer (selon le serveur, ce n'est pas défini dans la RFC) à tous les clients connectés les messages que tu envoies, bref ce n'est pas ce qui se passe avec les interfaces de SàT. Mais ce n'est de toute façon pas le rôle du serveur de gérer ton historique. Par contre on peut envisager une XEP de synchronisation d'historique entre les clients (il me semblait qu'il y en avait une, mais en regardant apparemment de n'est pas le cas(*)).
Après, les jeux de Quiz, tout ça, c'est vrai que ça relève peut-être plus du client que du serveur, mais ça devrait pouvoir se faire de façon "générique": programmation en XMPP? On devrait avoir un environnement, une bibliothèque de fonctions haut niveau permettant de décrire un jeu, et pourquoi pas entrer ça dans des fichiers stockés sur le serveur qu'on télécharge dans le client XMPP.
J'aimerais bien proposer tout ça oui. Dans un premier temps une XEP générique pour les jeux de cartes, mais ça sera bon pour fournir un moyen de discuter et se mettre d'accord sur la gestion des règles, par pour tout le côté gestion du code du jeu. Après on peut aller jusqu'à faire un langage de description des jeux, on s'éloigne un peu de l'idée de base de XMPP que la complexité est côté serveur, mais c'est une possibilité que j'ai déjà envisagée (mais bon, y'a d'autres priorités pour le moment).
Bref! SàT peut-il être considéré comme une sur-couche haut niveau à XMPP que tu as choisi de séparer dans un démon?
Au final tu considères ça comme tu veux, ce n'est pas très important à mon sens :). Ce qui est important, c'est de garder une compatibilité avec les autres clients, et bien sûr de suivre tout le reste (être libre, protéger l'utilisateur, etc. Bref Le contrat social).
(*) Bon ben sur jabberfr on m'a redonné le numéro: la XEP-0136
[^] # Re: Un serveur client d'un autre serveur...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 3.
Presque, ce sont des frontends (interfaces) qui se connectent, et le démon est le backend
Non, c'est bel est bien un client. Tu pourrais remplacer le couple démon/D-Bus par bibliothèque ça reviendrait au même.
Un serveur XMPP communique avec un client de manière faite pour le réseau, alors que le démon communique avec les interfaces en se considérant en local (même si ce serait techniquement possible d'avoir des interfaces à distance, mais c'est une autre histoire), des messages sont envoyés en permanence pour D-Bus, des signaux pour le moindre texte envoyé ou reçu. Le démon gère des choses qui n'ont rien à voir avec XMPP: par exemple les plugins peuvent fournir des UI génériques aux frontends, j'ai un plugin qui permet de lire/envoyer des messages couchsurfing, ou de se créer des serveurs IMAP/SMTP, ce n'est pas du tout le rôle du serveur XMPP de faire tout ça.
Pareil, le démon gère le stockage et la manipulation de l'historique, ou de ton roster.
Les fonctionnalités que je désire et qui ne sont pas implémentées de base dans le serveur, c'est via des extensions au protocoles (des XEPs) que je les implémenterai (modulo la XEP est validée).
SàT est vraiment un client, il a juste une séparation forte entre la vue et le métier, ou entre la vue et le couple modèle/contrôleur dans un modèle MVC.
Une priorité positive égale ça pourrait envoyer (selon le serveur, ce n'est pas défini dans la RFC) à tous les clients connectés les messages que tu envoies, bref ce n'est pas ce qui se passe avec les interfaces de SàT. Mais ce n'est de toute façon pas le rôle du serveur de gérer ton historique. Par contre on peut envisager une XEP de synchronisation d'historique entre les clients (il me semblait qu'il y en avait une, mais en regardant apparemment de n'est pas le cas(*)).
J'aimerais bien proposer tout ça oui. Dans un premier temps une XEP générique pour les jeux de cartes, mais ça sera bon pour fournir un moyen de discuter et se mettre d'accord sur la gestion des règles, par pour tout le côté gestion du code du jeu. Après on peut aller jusqu'à faire un langage de description des jeux, on s'éloigne un peu de l'idée de base de XMPP que la complexité est côté serveur, mais c'est une possibilité que j'ai déjà envisagée (mais bon, y'a d'autres priorités pour le moment).
Au final tu considères ça comme tu veux, ce n'est pas très important à mon sens :). Ce qui est important, c'est de garder une compatibilité avec les autres clients, et bien sûr de suivre tout le reste (être libre, protéger l'utilisateur, etc. Bref Le contrat social).
(*) Bon ben sur jabberfr on m'a redonné le numéro: la XEP-0136