ce petit journal pour vous annoncer que je viens de publier la première version de SàT, un client jabber sur lequel je travaille par à-coups depuis quelques mois.
Bon je vous dis tout de suite: c'est une ébauche, c'est moche, ça marche mal, ça respecte même pas complètement le protocole, c'est Q&D, malpas architecturé, bref c'est une preuve de concept.
Oui je sais aussi, y'a déjà trop de clients, j'aurais pu contribuer sur un autre, etc.
Bon bref les raisons sont simples:
- la plus importante: j'avais envie
- je n'ai pas vu de client avec l'architecture que je voulais
- je voulais un projet de moyenne envergure pour me perfectionner à Python et pour apprendre Twisted
- je voulais une brique pour d'autres projets que j'ai en tête.
Ça se présente sous forme d'un démon et de plusieurs frontends, communicant par DBus. En effet, je voulais un client capable de rester connecté même en fermant X, et indépendant de la vue.
J'essaye de créer une certaine abstraction du côté démon: c'est lui qui gère les demandes de confirmation, les barres de progression, etc. Les frontends ne fond qu'afficher et transmettre les activités de l'utilisateur.
Pour l'instant il y a les frontends suivant:
- wix (WX widgets): client classique
- sortilege (ncurses): client sobre, laissant le maximum de surface pour la communication
- jp (ligne de commande): outil de geek par excellence, j'en avais marre de parcourir des boites de dialogues pour envoyer ou recevoir un simple fichier.
et sont envisagés à moyen terme un frontend KDE 4 et un frontend Web (Ajax).
Il y a une bibliothèque censée permettre la création d'un nouveau frontend classique très rapidement (très mal architecturée pour le moment).
L'architecture permet de combler les lacunes d'un frontend par un autre: on peut imaginer des widgets qui gèrent chacun une partie d'un client. Ainsi sous KDE, on pourrait avoir un plasmoid qui se contente uniquement de gérer la roster list, un autre qui afficherait les conversations, les barres de progressions partiraient dans le gestionnaire de KDE.
Autre intérêt: un script peut se faire très facilement, un simple appel dbus peut lancer toute une série d'actions. Ainsi un script peut envoyer un fichier sans avoir à se soucier de gérer la connexion ou les barres de progression par exemple.
Les XEP sont implémentés sous forme de plugins. Permettant de sélectionner ceux qui nous intéressent, et a priori de les coder rapidement. Le projet se veut aussi un terrain de jeu pour essayer des protocoles expérimentaux.
J'ai décidé de le publier maintenant alors que le code est très moche et que le projet est inutilisable pour un usage quotidien pour suivre le célèbre "publish early, publish often".
D'autre part l'architecture a suivi étroitement le sens du vent et la position des étoiles; il est peu être temps de se poser un peu pour organiser ça mieux, et éventuellement avoir des avis externes.
Je publie ce journal pour avoir vos commentaires, voire vos attente.
Aussi si vous avez des envies, des idées de killer features, n'hésitez pas à en parler.
L'archive se trouve sur mon site: http://www.goffi.org
Ah, et c'est sous GPL V3, bien que j'ai hésité à mettre une licence plus permissive.
# Backend
Posté par Romain . Évalué à 4.
[^] # Re: Backend
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Mais d'une part je ne réimplémente pas le protocole: il est dans twisted et dans wokkel (une bilbliothèque par dessus twisted qui prépare les futurs ajouts à twisted), et d'autre part je voulais justement apprendre twisted et bien maitriser jabber, donc ce n'est pas plus mal d'implémenter ce qui ne l'est pas encore dans twisted.
Puis les autres protocoles ne m'intéressent pas (du moins pour le moment, j'envisage quelques exceptions pour un site ou deux), je veux faire un client jabber, pas un multiprotocole, surtout que jabber fournit déjà les transports.
# Oui mais
Posté par Éric (site web personnel) . Évalué à 1.
- Au lieu que chaque appli utilise une lib jabber, chaque appli va utiliser dbus avec une api ou un protocole propre à ton serveur local. Je ne vois pas bien où on gagne en simplicité.
- Le fait d'avoir un proxy local toujours "up" avec plein de clients revient à refaire en local l'architecture de jabber : Le serveur Jabber sait déjà gérer les événements quand tu n'es pas connecté et te les renvoyer plus tard, pas besoin d'avoir un proxy local "toujours connecté" qui redispatche. De même ton serveur sait déjà gérer des clients multiples, pas besoin d'un proxy local là non plus.
Le seul gain est celui que tu donnes, pouvoir cliquer sur le roaster d'une appli pour que ce soit une autre qui ouvre la fenetre de discussion. En pratique j'ai du mal à voir l'intérêt que ça aurait mais peu importe : ça va nécessiter de développer un mini protocole pour savoir passer un truc d'une appli à l'autre, ou dire à laquelle on destine quoi. Au final ça aurait pu être fait en n'implémentant que la couche dbus sur tes applications, que l'application qui gère le roaster sache envoyer un message "ouvre une conversation sur X" à celle qui gère les discussions. Chacun peut garder sa connexion directe au serveur jabber, tu n'as pas besoin d'avoir un proxy local jabber pour ça.
Non parce que à force tu vas te rendre compte que ça serait même méga génial que ton petit proxy dbus puisse aussi converser avec une appli distante sur ton NAS par exemple. Là tu vas ouvrir ton proxy "local" au réseau. Au final tu auras juste recréé un nouveau serveur jabber, ou plutot un proxy.
[^] # Re: Oui mais
Posté par suJeSelS . Évalué à 3.
[^] # Re: Oui mais
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Le démon n'a pas non plus le rôle de proxy: c'est lui qui gère toute la logique de l'application, les frontends ne servent qu'à représenter ça. Il se connecte et se déconnecte comme un client classique. Les choses que je transmets entre démon et serveur sont des choses qui se transmettraient de la même manière avec une bibliothèque (historique, roster list, informations de présence), bref ce n'est absolument pas un "nouveau serveur jabber" (un serveur fait quand même beaucoup plus de choses).
Le choix d'une archi autour d'un démon a été fait principalement pour les raisons suivantes:
- indépendance du serveur X, ça c'était dans mon cahier des charges, je voulais pouvoir redémarrer X en restant connecté
- les différents frontends peuvent s'utiliser en même temps: un use case qui me vient tout de suite à l'esprit parce que je l'utilise déjà comme ça: j'utilise le client graphique la plupart du temps, mais je déteste devoir aller dans les boites de dialogue quand je suis en console et que je veux juste envoyer un fichier, je peux utiliser l'outil en ligne de commande (jp) et envoyer directement mon fichier, tout en continuant l'utilisation normale du client graphique. OK, DBus suffit à ce use case, mais jp gère également la réception du fichier et la barre de progression, c'est déjà moins évident avec un client classique.
- une autre chose dans mon cahier des charges: je me balade régulièrement entre plusieurs ordinateurs (portable et fixe), et je voulais pouvoir avoir la même conversation sur les machines sans contorsions du type VNC. Oui je sais il y a les ressources, très utiles avec par exemple un compte au boulot et un compte à la maison, mais elles ne permettent pas de recevoir le même message sur les 2 clients en même temps (en cas de priorité égale, c'est le dernier connecté qui reçoit). Avec ce modèle démon/frontend je peux (tiens je vois pas d'équivalent français pour frontend).
[^] # Re: Oui mais
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
- l'indépendance par rapport au toolkit graphique. Bon là ça peut se faire classiquement à coups de patrons de conceptions, disons que le modèle démon avec une abstraction des requêtes graphiques est une façon de faire.
# indépendance du serveur X
Posté par err404 (site web personnel) . Évalué à 3.
permettre à X de se couper et sans déconnecter la session jabber... c'est bien
mais il faut peut être conserver la possibilité dans les préférences de couper aussi en même temps que X, ou au choix, sur requête en mode ncurses par exemple.
ça serait une idée à implémenter pour Gajim, qui à mon avis ne le permet pas (encore) de fonctionner indépendamment de X
l'idée de séparer en plugins permet l'ajout de fonctionnalités et de support sur les nombreux XEP.
l'indépendance du serveur X permet de finir un transfert de fichier même si on se déconnecte de X, ça va être bien pratique pour les transferts un peu long.
# deux trucs betes
Posté par pikapika . Évalué à 1.
par contre :
- j'ai chope l'archive et je crois qu'il me manque des dependances, et ca aurait ete bien de lister ca dans le readme, voire de donner les sources
- un petit wiki aurait ete bien
en tout cas merci et bon courage
[^] # Re: deux trucs betes
Posté par Goffi (site web personnel, Mastodon) . Évalué à 1.
Le wiki c'est prévu, pas tout de suite tout de suite parce que j'ai plein de choses à faire, mais c'est prévu (et la doc sera faite dessus). Pour le moment je suis sur un dépôt mercurial chez moi, je vais essayer de monter une forge avec bugtracker et tout ce qui va bien (si possible auto hébergé, sinon j'utiliserai une forge associative).
Bon sinon il te faut installer twisted et wxpython, qui devraient être packagés sur la plupart des distros. Pour jp il faut aussi progressbar, qui se trouve ici: http://pypi.python.org/pypi/progressbar .
Pour utiliser, il faut d'abord lancer le backend sat (qui n'est pas encore démonisé, alors lancez le dans shell à part), puis utiliser wix pour régler les paramètres.
Je voulais faire une petite vidéo pour montrer le tout en action, mais ça n'a pas été très concluant, du coup je n'ai pas insisté.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.