Sommaire
Salut à Vous !
Cela fait maintenant un peu plus d'un an que la campagne de financement participatif s'est achevée avec succès et que nous nous sommes engagés à développer une interface bureau/Android de « Salut à Toi », outil de communication multi-interfaces et multi-usages basé sur XMPP.
Il est temps de faire un petit état des lieux du développement. Vous trouverez en bas de cet article un lien vers une première version (pré-alpha) POUR TEST UNIQUEMENT.
Comme la campagne a été abordée ici, il me semble normal de publier également sur DLFP.
Le contexte
Pour la petite histoire, nous entendions faire une campagne plus importante à l'origine quand nous avons décidé de faire un financement participatif. Mais suite à des discussions avec l'équipe d'Arizuka (plate-forme que nous avons choisie), nous avons largement réduit la somme demandée, ce qui s'est avéré judicieux puisque nous avons réussi la campagne : nous avons récolté 3 326,00 € sur les 3000 € demandés, soit 3 159,70 € après les frais.
Évidemment, cette somme est insuffisante pour vivre, aussi nous avons repris une activité salariée (j'en ai d'ailleurs parlé ici) et dû réduire le rythme de développement : je suis le seul développeur actif à l'heure actuelle (avec quelques contributions, notamment les accusés de réception et la authentification HTTP par XMPP par Chteufleur).
Ajouté aux choses annexes (gestion de l'association, écriture d'articles, projets liés, etc), ceci explique le temps de développement.
Cette aussi cette situation qui explique que nous avons réduit notre participation aux événements du Libre, ainsi vous ne nous avez pas vu au Fosdem cette année.
La plupart des contreparties promises aux soutiens ont été fournies (mais pas toute, certaines n'ayant pas encore été réclamées). La somme reçue n'a pas encore été utilisée, sauf pour les frais fixes (serveurs, plate-forme de paiement des cotisations, banque).
Si ceci vous intéresse, vous trouverez les détails dans le compte rendu de la dernière assemblée générale extraordinaire de notre association.
Cagou
Comme déjà annoncé, la nouvelle interface de bureau et pour appareils mobiles (Android pour le moment) de SàT s'appelle « Cagou », un clin d'œil à l'outil Kivy que nous utilisons, et à cet oiseau emblématique de la Nouvelle-Calédonie, oiseau qui ne vole pas et qui aboie.
Développement
Cette partie est technique, vous pouvez passer directement à la suivante si cela ne vous intéresse pas.
Après une petite phase de prise en main de l’écosystème de Kivy, la première étape a été d'intégrer « Quick Frontend » (frontal rapide) qui est une base que nous utilisons, comme son nom l'indique, pour développer rapidement un frontal et factoriser le code (gestion du cache, de la liste des contacts (« roster » en XMPP), des widgets, etc.), puis d'intégrer le « bridge » (pont) qui est le nom que utilisons pour l'IPC qui permet la communication entre le « backend » (démon qui gère le cœur de SàT) et les frontaux.
Cette phase s'est relativement bien passée, elle a été accompagnée d'une réflexion sur l'architecture et l'interface utilisateur.
Une fois ceci à peu près utilisable, le port sur Android a pu commencer.
Les choses ont été un peu plus compliquées. La communauté Kivy a créé plusieurs outils pour développeur sur cette plate-forme, dont python-for-android (outils de compilation et empaquetage) et Buildozer (outil multi-plateformes qui facilite l'utilisation du premier). La prise en main de ces outils demande quelques efforts, surtout pour un projet déjà en place (c'est nettement plus simple quand on commence directement avec Kivy et le port Android).
Il y a 2 « chaînes » de développement pour Android, l'ancienne et la nouvelle. Après des premiers tests non concluants avec la nouvelle, elle a été temporairement mise de côté pour l'ancienne le temps de développer les bases du port.
Les dépendances en Python pur s'importent facilement, mais dès que ça se complique un peu, il faut faire des recettes (« recipes ») pour indiquer à python-for-android comment faire la compilation. Heureusement, la plupart de celles nécessaires pour SàT (en particulier Twisted) étaient déjà disponibles, il a toutefois fallu les mettre à jour.
Une fois ces questions de dépendances et de chaîne de compilation réglées, et après le plaisir de voir un premier .apk apparaître (mais non fonctionnel). 2 autres gros problèmes se sont posés : D-Bus qui est le « bridge » principal n'est pas utilisable sur Android, et comment faire fonctionner backend et frontal en même temps ?
Étant novice pour le développement sur Android, j'ai dû lire beaucoup de documentation (qui ne manque pas heureusement) et après un premier essai avec un nouveau bridge « embedded » permettant d'avoir backend et frontal dans le même processus, c'est finalement l'écriture d'un bridge « pb » pour perspective broker, IPC de Twisted, qui s'est révélé être la meilleure solution. L'IPC d'Android est aussi une piste à explorer à l'avenir.
Pour lancer le backend, Kivy fourni des outils permettant de le lancer comme service Android, ce qui permet de le garder en arrière plan et de pouvoir gérer les messages et autres activités quand l'interface n'est pas visible pour l'utilisateur (ce qui signifie sur Android que l'interface est gelée jusqu'à ce qu'elle soit de nouveau sélectionnée par l'utilisateur).
Cette section est déjà bien longue, aussi je vous passe les autres difficultés (comme l'absence de widget gérant le HTML), parlons maintenant de l'interface.
L'interface
Cagou est donc utilisable sur bureau (GNU/Linux, mais probablement d'autres plates-formes également) et sur Android.
La version actuelle est une pré-alpha, l'.apk plus bas est fourni uniquement pour se faire une idée. Elle est très boguée, ne vérifie pas encore les certificats sur serveur, les enregistrements SRV ne sont pas pris en compte sur Android, etc. Elle est fournie pour d'une part montrer l'avancement, et d'autre part profiter des retours suffisamment tôt dans le développement pour prendre une bonne direction.
concepts de base
L'interface de Cagou est inspirée de celle de l'excellent Blender. En particulier la sélection de widget et la possibilité de faire des divisions à volonté en faisant glisser les bords du widget. Les grosses barres actuelle devraient disparaître à terme pour un bouton plus discret, probablement là encore inspiré de Blender. L'idée est qu'un utilisateur novice puisse changer de widget intuitivement, et qu'un utilisateur avancé puisse utiliser cette fonctionnalité.
La liste des contacts n'est pas l'élément principal de l'interface, elle peut être affichée si souhaité, mais n'est pas nécessaire à l'utilisation de Cagou.
Le menu en haut, pour le moment tout le temps visible, ne devrait être disponible que sur bureau, sur Android le bouton menu ou un bouton flottant vont probablement le remplacer d'ici la sortie stable.
Si vous avez des notifications, elles apparaissent pendant quelques secondes en haut, mais vous pouvez le lire en prenant votre temps en caressant la tête du cagou qui apparaît alors en haut à gauche.
Dans le cas d'événements nécessitant votre intervention (par exemple une autorisation d'accès via XMPP sur un site), un cagou apparaître sur la droite, et l'interface n'apparaître qu'après l'avoir touché. L'idée est ne jamais avoir de fenêtre modale (type « pop-up ») qui surgit et vole le focus alors que vous faites autre chose. Ces dernières n'apparaissent que suite à une action de l'utilisateur.
Dans le cas d'Android, il est possible que ces notifications soient remplacées par le système de notification natif, mais le choix n'est pas arrêté puisque l'historique des messages ne serait alors plus disponible.
Pour changer de mode (de widget), il suffit de cliquer sur le bouton en haut à gauche du widget actuel. Il n'y a actuellement que 4 widgets : le sélecteur qui affiche tous ceux disponibles, la configuration, la liste de contacts, et le chat. D'autres sont à venir, en particulier le blogage.
À l’intérieur d'un widget (uniquement pour la messagerie instantanée pour l'instant), il est possible de faire un mouvement de glisser horizontal pour passer d'une conversation ouverte à une autre.
Pour le moment ça n'est pas évident à utiliser la première fois (il faut faire un mouvement vif), il y a des petits réglages à prévoir.
Comme pour le reste de SàT, Cagou est prévu dès l'origine pour fonctionner avec des greffons et être facilement extensible. Tous les widgets et système d'envoi de fichiers (voir plus bas) sont des greffons.
messagerie instantanée (chat)
Comme nous voulons une interface utilisable sur petits écrans, simple, mais qui ne sacrifie pas les fonctionnalités, il faut trouver un compromis entre les informations affichées/ables à l'écran et les éléments/boutons permettant des actions. Trop d’éléments compliquent l'interface et prennent de l'espace, mais trop peu rendent les actions difficiles d'accès.
La disposition choisie actuellement (qui peut évoluer) consiste en un en-tête avec une barre de saisie et un bouton (en plus du sélecteur de widgets), le corps avec les messages, et une barre de saisie avec un bouton également.
Pour discuter avec un ou des contact(s), entrez des lettres faisant partie de son nom (n'importe où dans le nom). Pour le moment uniquement les identifiants (« jid ») et les conversations déjà ouvertes sont cherchés, mais à terme la recherche se fera également dans les noms, surnoms et dans les marque-pages.
Cagou détecte si vous voulez parler à une personne seule ou dans un salon de discussion, et s'adapte en conséquence.
Le chiffrement de bout en bout est de la partie, mais uniquement avec OTR (v2) à l'heure actuelle. Il est prévu d'intégrer OX (OpenPGP moderne) et OMEMO, mais il n'est pas certains que ça sera disponible pour la prochaine version (ça sera peut-être pour la 0.8). Pour l'activer, il suffit de cliquer sur le cadenas, ce dernier sera fermé si la conversation est chiffrée, et aura un point d'interrogation si votre correspondant n'est pas authentifié.
Passons directement à la barre de saisie. Vous trouverez sur la droite un bouton « + » qui sert pour le moment à ouvrir le dialogue d'envoi d'élément.
Ce dialogue comporte 2 boutons en haut, qui permettent de choisir si vous voulez téléverser votre fichier ou l'envoyer directement à un correspondant en pair à pair. Un texte en dessous indique en langage clair où votre fichier transitera, et si le chiffrement intervient (à l'heure actuelle tout est en clair pour les fichiers).
Le message texte est important pour que l'utilisateur comprenne bien où vont ses données, c'est une indication que l'on va sûrement placer à divers endroits stratégiques.
Les boutons en dessous sont les types d'envoi. Sur bureau il n'est actuellement possible que d'envoyer un fichier de votre arborescence, mais sur Android il est possible également d'envoyer une photo de votre galerie, d'en prendre une nouvelle ou de faire une vidéo, et d'enregistrer un message audio.
Voici à quoi ressemble l'enregistrement de messages :
et autour
En plus du travail sur Cagou lui-même, d'autres travaux ont été effectué.
Désormais indispensable avec l'utilisation sur appareils portables, la copie carbone a été implémentée. La gestion des archives sur le serveur est elle implémentée depuis longtemps pour le blogage, mais pas encore pour les messages, ça sera fait d'ici la sortie de la version stable.
La gestion des petits fichiers binaires (« BoB » pour « Bits of Binary ») est désormais disponible, son implémentation a notamment été motivée parce qu'ils sont utilisés par Movim.
Comme indiqué plus haut, les accusés de réception et l'authentification HTTP ont été implémentés par Chteufleur.
Depuis la 0.6.1 la gestion des messages a été améliorée, préparant notamment le terrain pour des fonctionnalités comme la correction du dernier message, prévue pour la version stable.
Plus récemment la gestion des composants (pour préparer les passerelles) et des blogs statiques sont également arrivés, mais nous en parlerons peut-être une autre fois.
soutien
C'est un appel que nous faisons souvent mais qui n'est pas toujours entendu, de l'aide serait grandement appréciée.
Ce peut être aussi simple que venir discuter avec nous (notre salon est à sat@chat.jabberfr.org, disponible en cliquant sur ce lien.
Si vous avez de quoi, une contribution financière serait bien sûr utile, nous avons récemment ouvert un compte sur Liberapay, suite a discussion résumée dans le compte rendu de l'A.G. lié plus haut. Notre objectif est de réussir dans un premier temps à travailler un jour par semaine sur SàT et de compenser la perte de salaire par des dons.
Vous pouvez aussi adhérer à notre association, toutes les infos sont par ici. Vous choisissez le montant de la cotisation (entre 0 et 100 €).
Et bien sûr des contributions, en particulier du développement, mais aussi des traductions, du graphisme, du thème CSS, de l'administration des serveurs. La plupart du développement est fait en Python, et c'est participer à un outil que vous utiliserez potentiellement tous les jours.
Parler de notre association et projet autour de vous est toujours utile.
Je crois que l'essentiel est dit pour cette fois, j’essaierai de tenir informé avec des billets (sur mon blog) moins longs les prochaines fois.
Ah, et le lien vers la pré-alpha actuelle (encore une fois: POUR TEST UNIQUEMENT): https://www.goffi.org/public/Cagou-0.1-debug.apk
# Divers
Posté par dzecniv . Évalué à 4.
Salut,
ce serait super. Votre employeur est-il ok pour vous passer à temps partiel ? J'aimerais y arriver aussi, sans nécessairement une compensation de salaire. Je serais tellement content ! La compensation aurait du sens pour un temps long dédié au logiciel, à mon avis.
y a-t-il une liste de tâches faciles ? pas vu sur votre bugzilla.
connaissant python, je serais potentiellement un de ceux qui installent la version de dév et regardent ce qu'il y à améliorer. Mais je trouve que vous ne rendez pas la chose facile: hg, bugzilla et pas github/gitlab et un gestionnaire de tickets plus moderne. Et il y aura une difficulté en plus si vous utilisez comme je vous en ai entendu parler, brython ou un truc du genre à la place d'un framework JS. Certes, l'image docker simplifie l'installation. Mais surtout je trouve que vous restez très techniques et que vous ne parlez pas bien aux potentiels utilisateurs, dont je suis aussi (surtout?).
Et le thème CSS… a besoin d'un contributeur ou contributrice :S
Bonne continuation !
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
salut,
Ce sont des choses à négocier, mais vu le temps que ça prend sur ma vie, il va falloir trouver une solution et celle là semble la plus réaliste à l'heure actuelle.
À une époque on avait fait une TODO list sur le wiki, mais avec le faible nombre de contributions et l'évolution constante du projet, on n'a pas maintenu. Le plus simple est de venir sur notre salon XMPP (sat@chat.jabberfr.org) pour en discuter.
Il y a quelques XEPs qui seraient sympa à implémenter (par exemple blocking command serait assez trivial à faire), ça se passe côté backend et il y a un tuto écrit ici: écrire un greffon pour SàT.
On peut aussi faire de l'amélioration de CSS (on va réécrire Libervia pour la 0.8, mais ça serait pas mal de rafraîchir), du thème (je viens de commencer à réécrire le système de thèmes pour le blog statique), de la traduction, ou prendre un bug qui semble abordable dans la liste.
Mercurial est utilisé depuis le début du projet, et bugzilla est là depuis longtemps aussi, c'est toujours utilisé parce que ça fait le boulot et que changer demande du temps qu'on consacre plutôt au code de SàT.
On a abordé l'utilisation de Gitlab/Github dans la dernière A.G. (celle dont je parle dans le journal si je ne m'abuse, du coup le résumé doit être dans ce compte-rendu), ainsi que d'implémenter l'authentification XMPP dans Bugzilla pour éviter d'avoir à créer un compte. Github a été écarté par cohérence, Gitlab reste une option.
Cependant on a toutes les briques pour faire notre propre outil de rapport de bogues basé sur XMPP maintenant (et donc décentralisé), c'est en gros une version spécialisé du blogage qu'on gère déjà (en tout cas dans notre cas pas besoin de plus, du moins pour le moment), et ça permet d'avoir un cas concret, c'est a priori ce qui va être fait dans un futur que j'espère proche.
Brython ne sera utilisé que pour l'interface Web, et devrait être beaucoup plus simple à installer que Pyjamas que nous utilisons actuellement. Ce n'est pas plus compliqué qu'apprendre un framework JS (même plutôt plus simple vu qu'on ne change pas de langage), et ça ne sera de toute façon pas utilisé pour les pages statiques.
Effectivement on a parfois un problème de communication, il ne faut pas hésiter à nous le dire et à nous demander si quelque chose n'est pas clair. C'est difficile de ne pas être technique quand on a la tête dans le code à longueur de temps, en plus sur linuxfr j'ai tendance à aller plus dans les détails qu'ailleurs.
Oui, d'ailleurs quelqu'un était venu proposer un thème CSS pour le blog statique sympa comme tout, je voulais l'intégrer mais depuis on ne le voit plus sur le salon :(. Sinon Libervia va être réécrit pour la version 0.8 (pas celle à venir, la suivante), et il va y avoir un gros coup de rafraîchissement graphique au passage.
merci !
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
et j'oubliais dans les choses à faire (mais c'est chiant et je le ferai sûrement moi même): les tests ! On a utilisé par le passé un buildbot, mais la couverture est à revoir, ainsi que le système de tests, c'est le chantier que je comptais faire pendant la phase de bêta et que les fonctionnalités seront gelées.
[^] # Re: Divers
Posté par dzecniv . Évalué à 3.
oui mais si je connais déjà un framework JS, ce qui est plus courant, je peux participer à SàT. Je risque moins d'apprendre Brython. D'où moins de coups de mains possibles, que vous déplorez.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
sauf que celui que tu connais n'est peut-être pas celui qui sera utilisé. Et JS plus que tout autre écosystème demande une mise à jour permanente, et potentiellement des refactoring ou changements d'outils (je sais qu'on est vendredi).
Si tu souhaites contribuer à SàT, il vaut mieux avoir des notions de Python (c'est un « tu » général vu que tu en as déjà). À partir de là, tu sais utiliser Brython ou Pyjamas.
[^] # Re: Divers
Posté par dzecniv . Évalué à 5.
en fait tu m'as répondu de manière typique, je trouve.
Vos choix sont peut être justifiables, mais, selon moi, ça diminue les chances de coup de main.
et bim, redirection vers un papier xmpp ! Je me dis "c'est forcément technique et trop dur pour 20min par ci par là". Réponse très technique.
vous préférez avancer que rendre les contributions + faciles. Ok.
ça a l'air génial, mais ce n'est pas fait, et c'est plus compliqué et atypique qu'un gitlab, donc ça diminue des chances de coup de pouce.
argument pour des tickets d'une forge, type gitlab :)
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Le tuto lié ne parle de XEP, tu peux commencer par là pour jouer un peu.
Après implémenter une fonctionnalité XMPP, ça passe 9 fois sur 10 par une XEP, ça peut sembler difficile quand on n'en a jamais fait, mais en pratique ça ne l'est pas : ça explique juste précisément ce qu'il faut faire. Regarde celle là par exemple, tu verras que ça n'est pas si compliqué: XEP-0245.
Puis je parle aussi de CSS, de traduction, d'ouvrir la liste de tickets pour en choisir un, etc.
Il ne faut pas exagérer non plus, les contributions ne sont pas difficiles. Mercurial n'est pas plus compliqué que GIT (c'est même plus simple), et si vraiment ça pose problème on peut même s'en sortir avec un envoi du code par courriel ou XMPP, les rapports de bogue ne sont pas non plus compliqués à faire (on accepte même ceux en Français si nécessaire).
quelqu'un qui disparaît je ne vois pas trop ce que ça va changer dans une forge. Enfin de toute façon Gitlab n'est pas exclus, et il nous manque un outil de revue de code c'est vrai.
[^] # Re: Divers
Posté par groumly . Évalué à 6.
Plus que diminuer les chances de coups de mains, ce fil est assez délirant.
On va réécrire ce truc, faire notre propre bug tracker, la chaîne de compilation a pas l'air piquée des hannetons, une architecture basée sur de l'ipc pour android (wat), et des blagues du genre "Y'a outil de compilation, mais trop complique, donc ya un outil pour utiliser l'outil, mais ca reste compliqué".
Je veux pas être méchant, mais quand les contributions manquent et que le projet est tenu à bout de bras par une seule personne, la priorité est de recruter (et donc de virer tout ce qui est un frein au recrutement, cf ce que dit dzecniv), et ensuite de limiter le scope pour pouvoir continuer à releaser fréquemment.
Penser ecrire son propre bugtracker et batailler contre un système de build ne me paraissent pas aller dans la bonne direction. Pour être tout à fait honnête, même avec une armee de contributeur, j'ai du mal à comprendre ce qui peut pousser qui que ce soit à écrire son propre bug tracker ('fin a part ceux dont le boulot est de faire des bug trackers, évidemment).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . Évalué à 1.
Sont quand même couillons chez Google, ils ont créé tout un système d'IPC alors que ça ne sert à rien sur Android, c'est bien connu.
Sont quand même couillons tous ces gens qui utilisent les autotools, cmake, scons, ant, etc.
# Cagou, Libervia, JP... STOP!
Posté par Le Gab . Évalué à 7.
Goffi je te le dis avec toute la bien-viellance possible, vous faites vraiment du tort au projet SàT avec votre taxonomie inconsistente.
Gardez ces saubriquets comme nom de code interne et n'exposez qu'une seule identité au public, à savoir: "Salut à Toi".
Je suis un utilisateur avancé et n'ai pas peur des expérimentations mais ici, même moi je suis largué. SàT c'est le nom du backend, c'est ça? Quand j'installe celui-ci quel est mon point d'entrée par défaut?
Il ne faut certainement pas faire un truc à la framachin mais avoir un fil rouge dans un projet aussi complexe peut faciliter la vie.
Je sais que vous y passer un temps certains et je ne souhaiterais aucunement saper votre travail et ou votre motivation mais vous avez l'occasion d'être un acteur majeur d'XMPP et je voudrais sincèrement que vous ayez le max de chance. Faites une pause dans les "features/XEP/56 UI", offrez un couple backend/frontend solid. Cagou peut attendre.
C'est déjà dur de faire entendre autre chose que Whatsapp et facebook mais dire aujourd'hui "dans le libre on a une alternative" en présentant le projet tel quel, c'est s'exposer au rejet pur et simple.
[^] # Re: Cagou, Libervia, JP... STOP!
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Tu as raison, et ça a aussi été abordé dans une A.G., il a été question un moment d'utiliser Libervia pour tout, et de faire Libervia web, Libervia desktop, Libervia cli, etc.
Ce n'est pour le moment pas une solution satisfaisante pour plusieurs raisons : déjà il peut y avoir plusieurs interface web/cli/etc., ensuite les noms n'ont pas été choisis aux hasard et ça chagrinerait de les passer à la trappe, et puis ça permet de différencier des choses différentes.
« Salut à Toi » (le projet dans l'ensemble) est au final plus une base pour créer des outils cohérents, et les frontaux sont les interfaces de ces outils.
Pour faciliter le lien, on précise maintenant systématiquement
(SàT)dans les noms.Il faut voir aussi que le nom « Salut à Toi » est un pied de nez au choix quasi systématique d'un nom court, qui sonne bien, de préférence anglophone, insipide et facile à retenir, en plus de la référence aux Bérus et d'un nom qui colle bien pour un outil de communication. Note que je n'ai rien contre les noms anglophones ou faciles à retenir, c'est juste le « quasi systématique » qui est ennuyant. La graphie en montagne russe (qui n'est d'ailleurs pas dans le titre de la chanson) couplé à la présence de l'accent sont un petit plus amusant. L'accent a d'ailleurs déjà permis de lever des bogues de mauvaise gestion unicode.
Le seul petit regret que j'ai sur ce nom, c'est qu'on m'a déjà dit qu'on pensait que le projet était réservé aux francophone.
Tout ça mis à part, ça serait bien oui de simplifier pour ne pas perdre les gens qui s'intéressent au projet.
Le développement de plusieurs frontaux permet de tester et améliorer l'architecture.
C'est encore trop tôt pour présenter SàT comme une alternative (la version à venir est justement prévue pour être la première qu'on puisse vraiment proposer au grand public). D'autre part on n'est pas la seule alternative, Movim, Xabber, Conversations peuvent être proposés également.
[^] # Re: Cagou, Libervia, JP... STOP!
Posté par Le Gab . Évalué à 3. Dernière modification le 24 février 2017 à 16:30.
Les suffixes ne sont même pas nécessaires. Mais bien sûr, la décision vous revient à vous seuls.
Je préfère que vous choisissiez "Salut à Toi" plutôt que "Libervia" qui fait un peu lourd à l'oral, après c'est mon ressenti, hein.
Tu n'as pas dû voir la plupart de mes interventions sur LinuxFR :), c'est mon coeur de bataille!
Et je crois même vous avoir fait un éloge quant à ce choix par le passé.
Bref raison de plus que SàT marque les esprits. :)
Que tu ne t'y trompes pas donc, l'anglish ou le côté FantaTropCool - voir mon commentaire sur Yunoshost, très peu pour moi.
Mais justement, je comprenais SàT comme étant une solution complète et cohérente de client et serveur. Une sorte de chainon manquant du monde XMPP. :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.